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Errata 
Hierarchical Correctness Proofs for Distributed Algorithms 
Nancy A. Lynch and Mark R. Tuttle 


(MIT Technical Report MIT/LCS/TR-387 dated April 1987) 


At the top of page 21, we make the following definitions: 


The action signatures {S;:7€ I} are compatible if for all 1,7 € I we have 
out(S;) 9 out(S;) = @ and int(S;) NM acts(S;) = 0. The objects {O;:7<¢ I} are 
compattoble if their action signatures are compatible. 


Add to these the following definitions: 


The action signatures {S;:7€ I} are strongly compatible if they are compatible 
and no action is contained in an infinite number of the action signatures S;. 
The objects {O;:1€ I} are strongly compatible if their action signatures are 
strongly compatible. 


Notice that a finite collection of compatible objects are strongly compatible, and that 
any result holding for compatible objects must also hold for strongly compatible objects. 
Lemma 7 holds only for strongly compatible schedule modules, and hence Corollary 8 and 
Lemmas 9 and 20 hold only for strongly compatible objects. 


Finally, the conclusion is missing from the statement of Lemma 30 on page 45. The 
final sentence of the statement of Lemma 30 should be “Then A satisfies B.” 
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Abstract 


This thesis introduces a new model for distributed computation in asynchronous 
networks, the tnput-output automaton. This simple, powerful model captures in a 
novel way the game-theoretic interaction between a system and its environment, and 
allows fundamental properties of distributed computation such as fair computation to 
be naturally expressed. Furthermore, this model can be used to construct modular, 
hierarchical correctness proofs of distributed algorithms. This thesis defines the input- 
output automaton model, and presents an interesting example of how this model can 
be used to construct such proofs. 
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Chapter 1 


Introduction 


A major obstacle to progress in the field of distributed computation is that many of the 
important algorithms, especially communications algorithms, seem to be too complex: 
for rigorous understanding. Although the designers of these algorithms are often able 
to convey an intuitive understanding of how their algorithms work, it is often difficult to 
make this intuition formal and precise. When these algorithms are rigorously analyzed, 
the work is generally carried out at a very low level of abstraction, involving messages 
and local process variables. Reasoning precisely about the interaction between these 
messages and variables can be extremely difficult, and the resulting proofs of correctness 
are generally quite difficult to understand. 


An indication that the situation is not completely hopeless is the fact that the 
designers are able to give high-level, although informal, descriptions of the key ideas 
behind their algorithms. For instance, the distributed minimum spanning tree algo- 
rithm of (GHS83] can be interpreted as several familiar manipulations of a graph. What 
is needed is a way of formalizing these high-level ideas, and incorporating them into a 
proof of the detailed algorithm’s correctness. 


One promising approach is to begin by constructing a high-level description of 
the algorithm. This description could stse/f be an algorithm in which high-level data 
structures (such as graphs) serve as states, and process actions manipulate these data 
structures. This algorithm could then be proven correct using rigorous versions of the 
high-level, intuitive arguments given by the algorithm’s designers. Successive refine- 
ments of this algorithm could then be defined at successively lower levels of detail, and 
each shown (rigorously) to simulate the preceding algorithm. Ideally, this approach 
would allow us to use in the proof of simulation any property that has already been 
proven for preceding levels. In this way, the high-level intuition used to explain the 
algorithm would become part of a rigorous proof of the full algorithm’s correctness. 


Two years ago, we began to consider this approach for a fairly simple but interesting 
algorithm for resource allocation in an asynchronous network, an algorithm originally 
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suggested by Schénhage in [Sch80]. Correctness conditions for this resource arbitration 
problem include both safety and liveness conditions:! the mutual ezcluston condition 
that at most one user is using the resource at any given time; and the no lockout 
condition that if every user holding the resource eventually returns the resource to the 
arbiter, then the arbiter will eventually grant the resource to every requesting user. The 
algorithm can be described at three levels of abstraction. At the top level is a simple, 
set-theoretic statement of the problem, itself described as an algorithm. At the second 
level is a graph-theoretic description of the arbiter, and how it moves the resource 
around the network. At the third and lowest level is a distributed implementation of 
the arbiter, describing in terms of messages and local process variables the protocol 
individual processors must follow. 


It soon became apparent, however, that traditional models and proof techniques (see 
[OG76], [LS84b], and [Hoa85], for example) are not adequate to describe interesting 
aspects of the problem statement, algorithm, and correctness proofs. In particular, 
while the problem seems most naturally formulated in terms of the game-theoretic 
interaction between the users of the arbiter and the arbiter itself, these models require 
that the problem be formulated in terms of system states, and do not capture this 
game-theoretic aspect of the problem in a natural way. Furthermore, the interaction 
between the users and the arbiter clearly distinguishes the arbiter’s input actions from 
its output actions. Input to the arbiter (a request for the resource) can occur at any 
time, regardless of whether the arbiter is in a position to grant the resource. Output 
(the granting of requests) occurs only under the control of the arbiter. This notion 
of control, the notion that one system component may completely determine when a 
particular action is performed, is not easily expressed in these models. We note that 
satisfaction of the no lockout condition requires that the arbiter be given “fair turns” 
to produce output, rather than simply being overwhelmed by a flood of input. The 
ability to express this notion of “fair turns” depends heavily on the ability to express 
the notion of one process controlling the performance of an action. 


We were therefore led to the development of a new model of distributed compu- 
tation in asynchronous systems, the input-output automaton. This model is based on 
(possibly infinite-state) nondeterministic automata. Automaton transitions are labeled 
with the names of process actions they represent. These actions are partitioned into 
sets of input and output actions, as well as internal actions representing internal pro- 
cess actions. Input actions have the unique property of being enabled from every state; 
that is, for every input action there is a transition labeled with this action from every 
state. In other words, the system must be able to accept any input at any time. Thus, 


1Informally, properties required of a program can be partitioned into safety properties and liveness 
properties. A safety property (such as mutual exclusion [Dij65]) says that nothing “bad” will ever hap- 
pen, and a liveness property (such as termination) says that something “good” will eventually happen. 
Alternatively, safety properties describe allowed behavior, and liveness properties describe required be- 
havior. Alpern and Schneider give formal definitions of safety and liveness in [AS86] in terms of Biichi 
automata. 


a very strong distinction is made between actions locally-controlled by the system (out- 
put and internal actions) and actions controlled by the system’s external environment 
(input actions). This distinction captures the game-theoretic interaction between the 
system and its environment alluded to above, and gives our model an event-driven 
flavor characteristic of many asynchronous distributed algorithms. 


In order to construct models of complex systems from models of simpler system 
components, we define a simple notion of automaton composition. Loosely speaking, 
the composition of a collection of automata is their Cartesian product, with a state of 
the composition being a tuple of states from the component automata, one from each 
component. In order to model communication, we require that automata synchronize 
the performance of common (shared) actions. If 7 is an output action of A and an 
input action of B, then performance of x by both automata models communication 
from A to B. With simple syntactic restrictions on the composition of automata, we 
ensure that composition preserves the notion of control mentioned above: No system 
component may block the performance of an output action by any other component. 


Since automata are able to receive every input in every state, it is possible for an 
automaton to be flooded with input without having the opportunity to perform actions 
required in response to the input received. The satisfaction of most interesting liveness 
conditions, however, requires that this does not happen. The notion of fair computation 
therefore plays a fundamental role in our model. Informally, a computation of a system 
is said to be fair if every system component is always eventually given the chance to 
take a step. Since an automaton may model an entire system as well as a single 
system component, it is necessary to retain certain information about the structure of 
the system being modeled. In particular, it is necessary to retain information about 
which actions are controlled by the same system component. With this information it is 
possible to determine from a given system behavior whether each system component has 
been given the chance to make computational progress infinitely often. We therefore 
associate with every automaton a partition of its locally-controlled actions (i.e., its 
internal and output actions). The interpretation of this partition is that each class 
consists of the locally-controlled actions of one system component. With this partition, 
we are able to define a simple notion of fair computation in our model. 


Since our model concentrates on the input-output interaction between a system 
and its environment (rather than system states), our notion of a problem to be solved 
is a collection of system behaviors (sequences of input and output actions) considered 
acceptable (rather than conditions on system states). An automaton may be considered 
a solution to such a problem if every behavior exhibited by the automaton is contained 
in this set of acceptable behaviors. The automaton solves the problem in the sense 
that any correctness condition satisfied by each behavior in this set is satisfied by each 
behavior of the automaton. As previously mentioned, however, fair computation is 
crucial to the satisfaction of most interesting liveness conditions. We therefore require 
only that the fair behaviors of an automaton solving the problem be contained in the 


set of acceptable behaviors. We note that it is easy to fall into trivial correctness 
definitions, allowing trivial or uninteresting solutions to a problem. Our condition 
that an automaton be required to accept any input in any state, together with our 
notion of fairness, avoids this problem. The requirement that input be constantly 
enabled ensures that our solutions are able to respond to all patterns of input. The 
use of fairness ensures that the correctness of an solution will be judged only by those 
behaviors in which the system is actually given the chance to make progress. 


Our simple correctness condition, the requirement that the fair behaviors of an 
automaton be contained in some set of acceptable behaviors, is not a new style of cor- 
rectness conditions. It can be found, for instance, in the work of Lynch and Fischer 
in [LF81], and is similar to Hoare’s notion of specification satisfaction in [Hoa85]. The 
simplicity of such correctness conditions do, however, lend a uniform structure to cor- 
rectness proofs in our model. Recall that our notion of a well-structured correctness 
proof involves a sequence of models M;,...,M,, each modeling an algorithm at succes- 
sively lower levels of detail. The proof of the algorithm’s correctness involves showing 
that each model “simulates” the previous model in the sequence. That is, that the set 
of (fair) behaviors exhibited by M; are contained in the set of (fair) behaviors exhibited. 
by M;_,. In this sense, each model M,-, determines a problem that the model M; is 
required to satisfy. The problem of showing that M; “simulates” M;-; is therefore the 
problem of showing that M; solves the problem determined by M,_;. As an aid in doing 
so, we develop the notion of possibilities mappings that enable us to relate behaviors of 
one automaton to another. 


We note that our model may be considered a special case of other models such as 
Milner’s CCS and Hoare’s CSP (see [Mil80] and [Hoa85]). Neither of these models, 
however, is entirely suitable for our purposes. In the first place, although Milner has 
found them to be mathematically superfluous in CCS, we find the notion of a process 
state a convenient descriptive tool when describing algorithms. More important, how- 
ever, is the fact that fairness is difficult to express in CCS. Notions of fairness that 
have been studied in connection with CCS can be classified as either weak fairness or 
strong fairness (see [CS84], [Par85], and [Fra86]). Weak fairness requires that if an 
action 7 is continuously enabled, then it must be performed infinitely often. Strong 
fairness, on the other hand, requires that » be performed infinitely often even if it is 
enabled only infinitely often. These notions of fairness, however, are not satisfactory in 
event-driven systems. In such a system, for example, a process is always able to accept 
interrupts, but should not be required to interrupt itself unless some external source 
requests the interrupt. The problem is again the notion of control discussed above. 
There is no notion in CCS of an interface between processes from which we can deduce 
which which process controls the performance of a given action. By making a clear 
distinction between input and output actions, and by restricting ourselves to a simple 
notion of composition, we find that fairness is very simple to describe in our model. 


Similar comments can also be made for CSP with respect to fairness (see [KdR83], 


[Rei84], and [Fra86]). In fact, CSP further complicates the problem by identifying 
a process with (among other things) all finite behaviors of the process. Since it is 
impossible to deduce the infinite behavior of a process from its finite behaviors, CSP 
precludes the study of infinitary properties such as fairness without extending the 
semantics of a CSP process. 


We note further that the complexity of the operations defined in CSP dooms the 
language to a complex semantics, making reasoning about systems of processes unin- 
tuitive and cumbersome. Reading between the lines of Hoare’s book {Hoa85], it seems 
that Hoare himself would prefer to retain for nondeterministic processes the automata- 
theoretic (trace-theoretic?) semantics he develops for deterministic processes. However, 
the first nondeterministic operation introduced by Hoare is the nondeterministic OR, M, 
an operation combining two processes P and Q to form a process PQ that nonde- 
terministically chooses (itself) to behave either like P or Q. A second operation, D, 
combines P and Q to form a process POQ allowing the environment to determine 
whether POQ behaves like P or Q. Both PNQ and POQ have the same traces (since 
each behaves either like P or Q), but differ subtly in the fact that the environment: 
has no control or knowledge of the choice PM Q makes between P and Q. Thus, it is 
possible for PM Q and PQQ to be placed in an environment offering an action 7 as 
input, causing PM Q to deadlock while POQ does not. This forces Hoare to make his 
first break from the trace-theoretic semantics of deterministic processes and define the 
notion of a refusal, a set of actions a process might refuse to perform. In our model, 
however, due to the unique property of input actions, a process will not block if its 
environment offers 7 as input. Thus, by suitably restricting our model, we are able to 
retain the intuitive, mathematically-tractable semantics of automata. 


We note that there are systems of processes that can not be expressed in our model. 
Clearly, one such example is a system in which one process can block the progress of 
another as in CSP. These omissions, however, are the result of deliberate decisions, 
since, for example, it would be easy to define a notion of composition that allows us 
to express the process blocking of CSP. The simplicity of our model and its ease of use 
are the result of a careful limitation of its scope. Our experience has been that our 
model is sufficiently general to allow description of a significant number of interesting 
systems. We note that our model has already been found expressive enough to de- 
scribe work in network algorithms (see [LLW87] and the third chapter of this thesis), 
concurrency control algorithms (see [LM86], [HLMW87], [FLMW87], and {GL87]), mu- 
tual exclusion algorithms (see {(Wel87]|), hardware register algorithms (see [Blo87]), and 
dataflow computation (see [Lyn86]). Furthermore, in many of these papers our model 
has been found to be extremely useful when identifying the interface between system 
components, and discovering a system’s natural decomposition. 


Just as popular models of computation do not seem appropriate for our work, 
popular proof techniques also seem inappropriate. For example, “Hoare logics” are 


2A trace is a sequence of actions performed by a system or process. 
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a well-known method for proving that programs satisfy partial correctness assertions. 
Loosely speaking, a partial correctness assertion is a statement about the behavior of a 
terminating program. A program is said to satisfy such an assertion if it is satisfied by 
every terminating execution of the program. Therefore, a partial correctness assertion 
says nothing about program termination, but describes what will be true if and when 
the program halts. Hoare describes in [Hoa69] a method for proving that sequential 
programs satisfy partial correctness assertions. His method makes use of the observa- 
tion, first noted by Floyd in [Flo67], that partial correctness assertions satisfied by a 
program S can be expressed in terms of predicates P and Q describing the program 
state before and after the execution of S. More formally, if P and Q are assertions 
about program variables and S is a program statement, P{S}Q denotes the assertion 
that if P is true before the execution of S begins, then Q will be true if and when S 
terminates. Given a few simple axioms, Hoare shows how to derive partial correctness 
assertions P{S}Q for arbitrary programs S. In the first step of the derivation, each 
statement S; of S is annotated with assertions P; and Q;. In the second step, each 
assertion P,{S;}Q,; is proven using axioms describing the various programming lan-. 
guage constructs. Finally, general rules of inference (independent of any programming 
language) are used to combine these assertions into a proof of P{S}Q. 


Hoare’s method has proven to be a very effective method of verifying sequential 
programs. Most interestingly, it is possible to write hierarchical correctness proofs. 
Each program module S can be specified by a partial correctness assertion P{S}Q. 
Having proven each assertion P{S}Q, these assertions can be used in the proof of 
the larger program without reference to the implementation of S. Furthermore, since 
reasoning begins with a collection of partial correctness assertions characterizing pro- 
gram behavior and proceeds via rules of inference, this process can be automated if 
programmers are willing to supply certain intermediate assertions. Compilers for the 
language Euclid, for example, attempt to construct as much of the proof as possible 
(see [LGH*78]). Apt has written a comprehensive survey of Hoare logics in [Apt81] 
and [Apt84]. 


In [OG76], Owicki and Gries extend Hoare’s method to distributed and parallel pro- 
grams. Here, too, each statement S; of each process S is annotated with assertions P; 
and Q,, and partial correctness assertions P{S}Q* are proven for each process S in 
isolation using a sequential programming logic similar to Hoare’s. Unlike sequential al- 
gorithms, however, it is possible for one process action to affect the state of another. In 
order to prove partial correctness of an entire system of process, it is necessary to prove 
that no process can invalidate assertions appearing in the sequential proof of another 
process’s partial correctness. Owicki and Gries refer to this condition as noninterfer- 
ence. For example, if P{S}Q appears in the proof of one process and the assertion R 
labels one statement appearing in another process, noninterference requires that the 
assertion (P A R){S}(Q A R) hold; that is, the execution of S does not invalidate R. 


SOwicki and Gries actually use the notation {P}S{Q}. 


This method of Owicki and Gries has been found to be quite successful, just as Hoare’s 
method has been found to be successful for sequential programs. Gries has constructed 
a nice proof of Dijkstra’s on-the-fly garbage collector in [Gri77], an algorithm with such 
fine interleaving that the only atomic action required is memory reference. Levin and 
Gries show in [LG81] how the method of Owicki and Gries can be used to verify CSP 
processes. Furthermore, Schlichting and Schneider show in {[SS84] how message passing 
primitives can be incorporated into this framework. 


As with sequential programs, the partial correctness of systems may be specified 
with partial correctness assertions of the form P{S}Q. Due to the possibility of process 
interference, however, it is not possible to specify the partial correctness of individual 
processes in terms of such assertions. The specification of a process must also describe 
its environment if such assertions are to be used. Without a description of its en- 
vironment, it is impossible to prove that a process satisfies most partial correctness 
assertions. Furthermore, modification of a single process requires redoing a major por- 
tion of a system’s proof of correctness since it must be shown that this modification 
does not violate partial correctness assertions appearing in the correctness proofs of 
other processes. Thus, both specifications and correctness proofs using partial correct-— 
ness assertions of the form P{S}Q lack an important modularity. We consider this 
lack of modularity to be a major problem in protocol verification. 


Lamport attempts to resolve this lack of modularity in [Lam80|. Here Lamport 
redefines the assertion P{S}Q to mean that if execution is begun anywhere inside S 
with P true, then executing S will leave P true while control is inside S, and will 
make Q true if and when S terminates. Such a definition is possible for Lamport since 
he allows the predicates P and Q to refer to program locations, whereas Owicki and 
Gries restricted P and Q to program variables. The advantage of Lamport’s scheme 
is that partial correctness assertions for an entire system can be verified given partial 
correctness assertions specifying each system component. After system correctness has 
been proven from component specifications, any implementation of the components 
satisfying their specifications can be used in the system’s implementation. Lamport’s 
method, however, is not without its difficulties. For example, suppose that S is a 
system component making heavy use of shared variables. It seems difficult to construct 
assertions P that are invariant throughout the execution of S without knowing how S 
uses these shared variables. 


In our method, the problem of modular specification disappears since an environ- 
ment is implicitly specified by the fact that input actions are continuously enabled. (In 
other words, anything can happen in the environment of a process.) As a result, if 
a partial correctness assertion can be proven about process behavior, the partial cor- 
rectness assertion holds regardless of the process’s actual environment. Thus in our 
method it is no longer necessary to prove noninterference after proving the correctness 
of individual processes. Furthermore, it is no longer necessary to redo any part of a 
correctness proof when a process is modified, other than the correctness of the mod- 
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ified process itself. (A similar consequence of such input requirements can be found 
in [MCS82], [Sta84], and [LM&86].) Also, notice that Hoare-style specifications do not 
make clear the interface between a system component and its environment. As pre- 
viously mentioned, this interface is crucial to the definition of fair computation. In 
contrast, our model clearly defines this interface as the set of actions the process can 
perform, together with information about which actions denote input and output of 
the process. 


We note that due to the generality of automaton transitions, partial correctness 
assertions describing automaton transitions similar to those of Hoare describing com- 
mon programming language constructs may not always be easy to find. However, if 
transitions are described in terms of preconditions that must be satisfied before an ac- 
tion can be performed, and the effect of an action on an automaton state, then partial 
correctness assertions can be constructed for each action. Furthermore, the general, 
language-independent rules of inference used in Hoare-like systems are clearly valid in 
our model of computation. Thus, while we do not make use of such arguments in our 
work, it 1s possible to construct Hoare-like proofs of partial correctness assertions in 
our model. 


Notice that partial correctness assertions describe safety properties, and not liveness 
properties. Since there is no notion of system computation in these Hoare logics, 
there is no notion of eventuality. We note that safety properties can often be used to 
prove liveness properties. For example, Owicki and Gries show in [OG76] how well- 
foundedness arguments can be incorporated into Hoare logics to prove termination of 
programs. Alpern and Schneider go farther in [AS85] and show that the verification 
of both liveness and safety properties can be reduced to proving what are essentially 
partial correctness assertions. However, the specification of a liveness condition in 
terms of partial correctness assertions is often an unintuitive formulation. 


A more natural expression of such properties is possible with temporal logic. Tem- 
poral logic was introduced by Pnueli in [Pnu77] as an adaptation of classical modal 
logic suitable for reasoning about concurrent programs. The two paper series [MP81b| 
and (MP81a] by Manna and Pnueli is a thorough introduction to the expression of prop- 
erties of concurrent programs, and the verification of these properties, using temporal 
logic. Here the meaning of a system computation is a sequence of system states. The 
fundamental temporal operators are the unary operator © and its dual ©. Loosely 
speaking, a computation satisfies the expression OP, pronounced “henceforth P,” if P 
is true throughout the computation; and a computation satisfies the expression OP, 
pronounced “eventually P,” if there is a point during the computation at which P is 
true. Many interesting properties of computation may be specified with these simple 
operators. For instance, the expression 0(P > OQ) states that the property P causes 
the property Q to hold; the expression OOP states that the property P holds infinitely 
often. 


Temporal logic is a useful abstraction with which to specify and reason about pro- 
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gram behavior. Since the meaning of a computation is a sequence of states, temporal 
logic is able to express liveness properties as well as safety properties, and these ex- 
pressions are typically quite concise. Since reasoning in temporal logic begins with a 
collection of axioms characterizing program behavior, and proceeds via general rules of 
inference, reasoning in temporal logic has potential for automation. Furthermore, while 
Hoare logics make use of inference rules that are independent of any programming lan- 
guage, most of the work in a Hoare-style proof deals with language-specific semantics. 
In contrast, reasoning in temporal logic is valid for all programs. The difficulty, of 
course, is in abstracting from an implementation to a temporal logic characterization 
of its behavior, and this problem is often swept under the rug. 


A great deal of work in temporal logic concerns reasoning about system correctness 
after system components have been specified in terms of temporal logic (see, for ex- 
ample, [HO80], [SM81], [OL82], ([Lam83], [Sta84] and [NGO85]). The most dramatic 
distinction between these works is the way in which temporal logic is used to describe 
system behavior. Schwartz and Melliar-Smith give purely temporal specifications of 
programs in [SM81]. In these specifications, even the notion of a process state has been. 
replaced by temporal specifications. Consequently, the resulting specifications are quite 
complex, involving nested “until” operators in addition to the temporal operators de- 
scribed above. These specifications are often difficult to understand, and difficult to 
reason about. On the other hand, Hailpern and Owicki make great use of the notion of 
program state in [HO80]. They add Asstory variables to the program state that describe 
the history of events over communication links, and reason about the values assumed 
by these variables. History variables are a convenient descriptive tool found in many 
proof styles, and the specifications produced by Hailpern and Owicki are generally easy 
to understand. The history variables, however, do not affect program behavior, and in 
proofs reasoning about history variables the history variables themselves seem extrane- 
ous. Between the extremes of [SM81] and [HO80] is the work of Lamport in [Lam83]. 
Here the process state modeled consists only of program variables, and temporal logic 
assertions describe the sequence of values these variable assume. Although an automa- 
ton state can be seen as a natural extension of history variables, our proofs tend to 
have a flavor similar to those of Lamport’s in (Lam83]. 


While a great deal of work has studied the problem of reasoning about systems after 
system components have been specified in terms of temporal logic, less has been devoted 
to proving that an implementation actually meets its temporal logic specification. One 
attempt is that of Owicki and Lamport in [OL82], improving on the work of Lamport 
in {Lam77]. Since safety properties can be proven using methods of Owicki and Gries, 
of particular interest is the style of proving liveness properties Owicki and Lamport 
describe. Owicki and Lamport construct diagrams called proof lattices that outline the 
structure of a proof of a liveness property. Informally, a proof lattice is an acyclic 
directed graph with a single entry node having no incoming edges, and a single exit 
node having no outgoing edges. Nodes of the graph are labeled with assertions. A 
node labeled A with outgoing edges to nodes labeled A;,..., A, denotes the assertion 
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that if A holds, then one of the assertions A,,...,A, must eventually hold; that is 
AD O(A1V...V.Ap,). Suppose each such assertion can be proven for a program. If the 
entry node is labeled with A and the exit with B, then the proof lattice amounts to a 
proof of the liveness property A > OB for the program. Manna and Pnueli extend the 
use of proof lattices in [MP84]. In this work, however, an automata-theoretic model 
of computation is explicitly defined, and proof rules are given for proving that each 
assertion denoted by edges of the proof lattice is satisfied by the system modeled by 
an automaton. We find this work a very satisfying example of how an automata- 
theoretic model of computation and temporal logic can be used together. Given an 
automata-theoretic description of system implementation, temporal logic provides a 
useful abstraction for reasoning about system behavior. While we have not fixed on 
one particular specification language, we feel that temporal logic and our automata- 
theoretic model of computation can work well together. In particular, through the 
use of automata we are able to incorporate temporal logic into hierarchical correctness 
proofs. 


The use of abstraction is an important aspect of our style of algorithm verification. 
Most work in the literature claiming to produce proofs with a hierarchical structure 
actually allow system components to be verified independently, and then combined 
to verify the correctness of the system. This notion of hierarchical verification is a 
restricted version of the notion we use in this work. Here we actually construct models 
of the entire system at conceptually different levels of abstraction, rather than merely 
combining local process states into global system states. 


Our work most closely resembles that of Lamport in [Lam83]. Here Lamport spec- 
ifies a program with a collection of state functions mapping program states into sets of 
values, a collection of instial condttions essentially defining the set of states in which 
the system may begin computation, and a collection of properties describing safety and 
liveness conditions. We note that the values to which states are mapped by state func- 
tions can be thought of as state variables describing relevant aspects of the system to be 
implemented. Furthermore, the properties included in the system specification define 
allowed and required changes in the values these variables assume. If these variables 
are collected into states, then the variables together with the properties essentially de- 
fine an automaton together with a collection of eventuality conditions restricting the 
computations of the automaton. If the program implementing the specified system is 
considered to be an automaton, as is implicitly the case in Lamport’s work, then the 
state functions can be thought of as mappings from an automaton describing the sys- 
tem at one level of abstraction to an automaton describing the system at a higher level 
of abstraction. This is the technique used in our work. Our work is an improvement 
on that of Lamport’s in the sense that we carry his style of specifications to its natural 
conclusion, making the automata-theoretic flavor of his work explicit. Furthermore, 
we make explicit his underlying assumption that what is important about a process 
is the externally observable behavior of the process. His work seems to imply that 
the variables and state functions must be describing some aspect of the system that 
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must appear in the implementation. We feel, however, that they are to be considered 
merely descriptive tools, and that the notion of subset containment used as the notion 
of correctness in this work is the notion of correctness actually underlying Lamport’s 
work. 


Other work similar to ours is that of Stark in [Sta84]. Many of the aims and ideas 
underlying his work are the same as ours, but his model is much more general than 
ours. We find our model to be simpler and easier to use than Stark’s, and expressive 
enough to describe most systems of interest. Work on hierarchical verification also 
includes that of Lam and Shankar in [LS84a]; Harel in [Har87]; and Lamport, Lynch, 
and Welch in {[LLW87]. Each of these techniques analyzes an algorithm by abstracting 
away certain portions of the algorithm (rather than mapping to an entirely different 
level of conceptual abstraction as we do here) and studying the remaining “image” of 
the original algorithm. To Lam and Shankar, the advantage of this method seems to 
be that it allows highly interdependent modules of a system to be studied in isolation. 
Lamport, Lynch, and Welch seem to be taking this notion of “projection” one step 
further. They show how projections onto different modules can be combined into a 
proof of the entire system, giving the proof a lattice-like structure. While still work 
in progress, their work seems to be shedding new light on the intellectual organization 
of protocol verification. The progress being made in their research can certainly be 
incorporated into ours. 


The remainder of this thesis consists of two parts. First, in Chapter 2, we formally 
define our model of computation and develop the machinery needed to use our model 
in the construction of hierarchical correctness proofs. Then, in Chapter 3, we illustrate 
the use of our model by proving the correctness of Schénhage’s distributed resource 
arbiter. Finally, in Chapter 4, we end with some concluding remarks, including some 
ideas for future work. 
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Chapter 2 


The Input-Output Automaton 
Model 


In this chapter we define the input-output automaton model. We begin with a formal 
definition of an input-output automaton, and define operations that may be performed 
on automata, including the composition of automata. We then show how fairness 
can be modeled with automata. Finally, we develop the machinery necessary to use 
automata in the construction of modular, hierarchical correctness proofs for distributed 
algorithms. 


2.1 Input-Output Automata 


Having informally described our model in the introduction, we now formally define 
an input-output automaton. Since the actions of an automaton define the interface 
between an automaton and its environment, it is convenient to be able to refer to 
this interface explicitly. Given three disjoint sets tn, out, and tnt of input, output, and 
internal actions, respectively, we refer to the triple (in, out, int) as an action signature S. 
We denote the sets tn, out, and int by in(S), out(S), and int(S), respectively; and we 
denote the entire set of actions in U out U int by acts(S). Since int is the set of 
internal actions, it is natural to refer to in U out as the set of external actions, denoted 
by ezt(S). Finally, we denote the set int U out of locally-controlled actions by local(S). 


An input-output automaton (or automaton) A consists of five components: 


1. a set states(A) of states, 
2. a set start(A) C states(A) of start states, 


3. an action signature sig(A), 
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4. a transition relation steps(A) C states(A) x acts(sig(A)) x states(A), with the 
property that for every state a and input action x there is a transition (a, 7, a’) 
in steps(A), and 


5. an equivalence relation part(A) on local (sig(A)). 


Notice that the transition relation steps(A) has the property that input actions are 
continuously enabled, as mentioned in the introduction. Notice, also, that the equiva- 
lence relation part(A) is the partition of the locally-controlled actions alluded to in the 
introduction. This partition will be used when we define the notion of fair computation 
in Section 2.2. 


We refer to an element (a, 7, a’) of steps(A) as a x-step from a to a’. It will occasion- 
ally be convenient to denote the step (a,7,a') by a — a’, and to denote the sequence of 
steps do ~4 a, --+ “3 ay by ao “>” ay. The step (a,7,a’) is called an input step if x is 
an input action, and output steps, internal steps, external steps, and locally-controlled 
steps are similarly defined. If (a,7,a’) is a step of A, then 7 is said to be enabled 
from a. Since every input action is enabled from every state, automata are said to be 
input-enabled. 


An ezecution fragment of A is a finite sequence ao7,a; ...%,a@, or infinite sequence 
@o%14,%2@2... of alternating states and actions such that (a;,7%(41,4;41) is a step of A 
for every s. An execution fragment beginning with a start state is called an ezecution. 
We denote the set of executions of A by ezecs(A). A state is said to be reachable if it is 
the final state of a finite execution. The schedule of an execution z is the subsequence 


of actions appearing in z, denoted by sched(z). We denote the set of schedules of A by 
scheds(A). 


We will soon consider certain subsets of an automaton’s executions or schedules 
(such as the set of fair computations) to be of particular interest. Since we will com- 
pose automata, it will be necessary to have ways of composing sets of executions or 
schedules as well. If these compositions are to be meaningfully related, however, cer- 
tain information about the structure of the original automata must be retained. In 
particular, it is important to retain information about the action signatures of these 
automata. We are therefore led to define the notions of execution modules and sched- 
ule modules, essentially sets of executions or schedules, respectively, together with an 
action signature. 


An ezecution module E consists of a set states(E) of states, an action signature 
sig(E), and a set ezecs(E) of executions. Each execution of E is an alternating sequence 
of states and actions of E beginning with a state, and ending with a state if the 
sequence is finite. Each execution z has an associated schedule sched(z) that consists 
of the subsequence of actions appearing in x. We denote the set of schedules of E by 
scheds(E). An execution module E is said to be an execution module of an automaton A 
if E and A have the same states, the same action signature, and the executions of E 
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are contained in the executions of A. Notice that an execution module E is always 
an execution module of some automaton. In particular, E is an execution module 
of the automaton having the states and action signature of FE, and the transition 
relation states(E) x acts({sig(E)) x states(E). We denote the execution module of 
the automaton A having ezecs(A) as its set of executions by Ezecs(A). (We follow 
the convention of denoting sets with lower case names and modules with capitalized 
names.) 


A schedule module S consists of an action signature sig(S) together with a set 
scheds(S) of schedules. Each schedule of S is a finite or infinite sequence of the actions 
of S. Given an execution module £, there is a natural schedule module associated 
with E consisting of the action signature and schedules of E. We denote this schedule 
module by Scheds(E), and write Scheds(A) as shorthand for Scheds(Execs(A)). 


We refer collectively to automata, execution modules, and schedule modules as 
objects, the type of an object determining whether it is an automaton, execution module, 
or schedule module. For notational convenience, given an object O we often omit 
reference to its action signature and write, for example, in(O) for in(sig(O)). 


Since it is typically the case that more than one automaton can model the same 
process, some notion of equivalence is needed. Intuitively, the external observer of a 
process (a user of the process, for instance) can detect only the sequence of actions 
performed by the process. In fact, the only actions detectable by such an observer 
are the external actions of the process. We are therefore led to define a notion of 
equivalence determined by the externally visible sequences of actions produced by an 
object. Since we will consider in Section 2.2.2 a second notion of equivalence based on 
the fair behavior of an object, we refer the the current notion of equivalence as unfair 
equivalence. 


We begin by defining an operation that essentially extracts the externally visible 
behavior of an object. An ezternal action signature is an action signature consisting 
entirely of external actions; that is, having no internal actions. The external action sig- 
nature of an object O is the action signature obtained by removing the internal actions 
from the action signature of O. An ezternal schedule module is a schedule module with 
an external action signature. Given a sequence y of actions and a set II of actions, we 
denote by y|II the subsequence of y consisting of actions from II. The external schedule 
module of an object O, denoted by Ezternal(O), is the external schedule module with 
the external action signature of O and the schedules {y|ezt(O) : y € scheds(O)} ob- 
tained by removing the internal actions from the schedules of O. We define the unfair 
behavior of O, denoted by Ubeh(O), to be the external schedule module Ezternal(O). 


Two objects O and P of the same type are said to be unfairly equivalent, denoted by 
o ““E p, if Ubeh(O) = Ubeh(P). This equivalence is clearly an equivalence relation, 
and we will see that it is also a congruence with respect to the operations we now define 
on objects. 
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2.1.1 Composition 


To build models of complex systems, we compose models of simpler system components. 
In this section we show how to compose objects to construct such models. 


Composition of Automata 


Informally, the composition of a collection of automata is their Cartesian product, with 
the added requirement that automata synchronize the performance of shared actions. 
That is, each automaton is allowed to take steps independently, with the restriction 
that if one automaton takes a x-step, then all automata sharing 7 as an action must 
also take a x-step. This synchronization models communication between system com- 
ponents: If 7 is an output action of A and an input action of B, then the simultaneous 
performance of x models communication from A to B. Since synchronization is meant 
only to model communication, however, two automata sharing * as an output action 
should not be required to perform 7 simultaneously. We note that two processors. 
cannot be expected to perform an output action simultaneously in an asynchronous 
system. Rather than complicate the notion of composition, we require instead that the 
output actions of composed automata be disjoint. Since internal actions are meant to 
model externally undetectable actions, we are faced with the need for a similar restric- 
tion for internal actions. We require that the internal actions of each automaton in a 
composition be disjoint from the actions of the remaining automata. 


Having restricted the composition of automata to those with suitably compatible 
action signatures, determining the type of an action in a composition is fairly simple: 
Output actions of the component automata become output actions of the composition, 
internal actions of component automata become internal actions of the composition, 
and all remaining (input) actions of the component automata become input actions of 
the composition. Notice that the composition of automata does not hide communication 
between component automata. To hide such communication will require the use of a 
hiding operation defined later in Section 2.1.2. 


Finally, recall that associated with every automaton (in particular, with a compo- 
sition of automata) is a partition of its locally-controlled actions. Our intuitive under- 
standing of this partition is that each class represents the locally-controlled actions of 
one system component. A natural partition of a composition’s locally-controlled actions 
is to place the locally-controlled actions of each component automaton in a separate 
class. Since the restrictions we impose on the composition of automata ensure that 
the locally-controlled actions of the component automata are disjoint, this is indeed 
a partition. However, each component automaton may model many system compo- 
nents. We therefore partition a composition’s locally-controlled actions by taking each 
class of each component automaton as a separate class of the composition’s partition. 
That is, the partition of a composition’s locally-controlled actions is the union of its 
components’ partitions. 
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We are now in a position to formally define the composition of automata. We begin 
by defining a composition of action signatures. Previous discussion suggests that the 
action signatures {S; : 1 € I} be called compatsble if for all 1,7 € I we have 


1. out(S,;) N out(S;) = 0, and 
2. int(S;) O acts(S;) = 0. 
In general, we say that the objects {O; : 1 € I} are compatible if their action signa- 


tures are compatible. The composition S = [],¢; 5; of compatible action signatures 
{S; : « € I} is defined to be the action signature with 


1. in(S) = U in(S;) — U out(S,), 
ier ier 

2. out(S) = U out(Si), and 
i€ 


3. int(S) = U snt(S;). 
‘el 
Notice that this composition is commutative and associative. 


The composition A = [];¢, A; of compatible automata {A; : ¢ € I} is defined to be 
the automaton with 


pus 


. states(A) = iT states(A,), 
2. start(A) = TI start(A.), 

3. sig(A) = HT si9(Ai), 

4. part (A) = U part(A:), and 


5. steps(A) equal to the set of triples ({a;} , 7, {a{}) such that for all s € I 


(a) if  € acts(A;) then (a;,7,a{) € steps(A;), and 
(b) if x ¢ acts(A,) then a; = a}. 


Notice that since the automata A, are input-enabled, so is their composition, and hence 
their composition ts an automaton. When J is a finite set {1,...,n}, we will frequently 
denote the composition []; A; by A,-+...+ An. 


As a simple example of automaton composition, consider the two automata A and B 
shown at the top of Figure 2.1, and their composition A- B shown at the bottom of the 
same figure. (A caret points to the single initial state of each automaton.) The action a 
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Figure 2.1: An example of automaton composition. 


is an output action of A and an input action of B, and the action @ is an output action 
of B and and input action of A. Notice that since each waits for the other to take an 
output step before taking an output step itself, the automata A and B alternate output 
steps in executions of the composition A- B. Notice, furthermore, that since a and 3 
are output actions of A and B, respectively, all actions of the composition A- B are 
output actions. Finally, notice that the partition of the composition’s locally-controlled 
actions (in this case, the output actions) places a and G in separate equivalence classes. 


The composition of automata has two simple properties. First, an execution of a 
composition A = |]; A; always induces executions in the component automata A;. If 
a = {a;} is a state of A, let alA; = a;. If z = ag, a, ... is an execution of A, let z|.A; be 
the sequence obtained by deleting x;a; when 7; is not an action of A;, and replacing 
the remaining a; with a;|A;. We now have the following: 


Lemma 1: If z € ezeca([] A;), then z|A; € ezees(A,) for all ¢ € J. 
‘er 


Proof: Let A = |]; A;, and suppose that z = agm,a,.... By the definition of an 
execution, ao is a start state of A, and every triple (a,-1,%%,@4) is a step of A. Two 
facts follow from the definition of the composition A. First, ag|A; must be a start state 
of A;. Second, if 7, is an action of A; then (ag_1|A;, 7, @4|A;) is a step of A;. If 7, is 
not an action of A; then a,_,|A; = a,|A;. Thus, if z|A; = 89015;..., then 8 is a start 
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state of A;, and every triple (s;-1,0;,8;) is a step of A;. Therefore, z|.A; is an execution 


of A,. 


Conversely, under certain conditions an execution of a composition is induced by 
executions of its components. Here and elsewhere, we denote ylacts(O) by y|O for 
arbitrary objects O. 


Lemma 2: Let {A; : ¢ € J} be a collection of compatible automata. Let z; be an 

execution of A; for every 1 € I, and let y be a sequence of actions from the A;. If 

y|A; = sched(z,) for every + € I, then there is an execution z of [J;¢, A; such that 
= sched(z), and z; = 2|A, for every ¢ € I. 


Proof: Let A = []; A;. Suppose that y = m173.... Since y|A; = sched(z,;), we can 
write z; = ain;,ain,a).... Let ip = 0. Let z = aom,a,... where a; is defined as 
follows: If t. < j < te41, then a;|A; = ai. That is, the automaton A; remains in 
state ai, between the performance of actions 7;, and 7;,,,, and changes state to aj,,_ 
upon the performance of 7;,,,. First, we claim that ao is a start state of A. Since for 
all i we have that #9 = O implies ao|A; = ai, a start state of A;, we are done. Second, 
we claim that (a;-1,%;,@;) is a step of A for all 7. Suppose 7; € acts(A;). Then 
m; = ™, for some k. It follows that a;_,|A; = a4_, and a,;|A; = aj since th) <7 = ty. 
Thus, (a;_1|A,,7;,a;|A;) is a step of A;. Conversely, suppose 7; ¢ acts(A;). Then 
th < J < %e41, and it follows that a;_,|A; = ai = a;|A;. In either case, (a;-1,7%;,4;) 
is a step of A for all 7. It follows that z is an execution of A, and furthermore that 
y = sched(z) and z|A; = 2; for all 4. CO 


The following corollary, essentially Lemma 4 from [LM86], ensures that composition 
preserves the notion that a system component controls the performance of its own 
locally-controlled actions. As a result, when reasoning about the enabling of an action in 
a composition, it is enough to reason about the enabling of the action at one component. 


Corollary 3: Let y be a finite schedule of a composition A = [ley A;. Let x be a 
locally-controlled action of A;, and let y/ = ym. If y'|A; is a schedule of A;, then y’ isa 
schedule of A. 


Proof: Since y is a finite schedule of A, there is a finite execution z of A such that 
y = sched(z). By Lemma 1, 2|A; is an execution of A; for every j € I. Since x isa 
locally-controlled action of A;, if x is an action of A; (for any j # #), then x is an input 
action of A;. Since the A; are input-enabled, and since y’|A; is a schedule of Aj, for 
every j € J there is an execution z/, of A; such that y'|A; = sched(z;). By Lemma 2, 
there is an execution 2’ of A such that y = sched(z’), and hence y is an execution of A. 


Cl 
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Composition of Execution Modules 


We now define the composition of execution modules. The composition E = Ile; E; 
of compatible execution modules {E; : 1 € I} is defined as follows. The states of E 
are |],¢, states(E;), and the action signature is [];<; s1g9(E;). Given a state s = {s,;} of 
the composition, we define s|E; = s;. Given a sequence z = 809718)... of states and 
actions of EF, we define z|E; to be the sequence obtained by removing 7;s8; if 7; is not 
an action of £;, and replacing the remaining s,; by s;|E;. The executions of E are those 
sequences 89718... such that for every : € I we have that z|E; is an execution of EF, 
and that s;_1|E; = 3;|£; whenever x; is not an action of E;. The next lemma gives an 
alternative characterization of the composition of execution modules. 


Lemma 4: Let {E; : 1 € I} be a collection of compatible execution modules. Sup- 
pose FE; is an execution module of an automaton A; for every 1 € J. Then [],¢, E; is 
the execution module of [];<7 A; with executions z such that z|A, is an execution of £; 
for every 1 € I. 


Proof: Let E = [], Z; and A = J], A,. Since FE; is an execution module of A,, it 
follows that E; and A; have the same states and action signature, and hence so do E 
and A. We need only check that the executions of E are the executions z of A such 
that z|A; is an execution of E;. Suppose z is an execution of E. The execution z is 
a sequence 897%18,... of states and actions of E such that z|E; is an execution of £;, 
and s;_,|E; = s;|E; whenever x; is not an action of E;. Since E; is an execution 
module of A,, (8;-1|A;,7;,8;|A;) is a step of A; whenever 7; is an action of A;, and 
8;-1|A; = 8;|A; whenever 7; is not an action of A,. It follows that z is an execution of A, 
and furthermore that z|A; is an execution of E; for every 1 € I. Conversely, suppose z 
is an execution of A such that 2|A; is an execution of E; for every t € I. Clearly, z 
is a sequence 8978,... of states and actions of E such that z|K; is an execution of £; 
for every : € J. Furthermore, from the definition of the composition of automata we 
see that s,;_,|EZ; = s;|E; whenever 7; is not an action of E;. It follows that z is an 
execution of E, as desired. C 


This composition is defined so that the following result holds. 


Lemma 5: For all compatible automata {A; : 1 € I}, 


Ezees([] Aj) = [] Execs(A,). 


el tel 


Proof: Let A = [],; A;. Furthermore, let EC = Exzeca([]; A;) and CE = J]; Ezecs(A;). 
Notice that EC is an execution module of A. Furthermore, since Ezecs(A;) is an 
execution module of A; for every : € J, Lemma 4 implies that CE is also an execution 
module of A. It follows that EC and CE have the same states and action signature. 


24 


We need only show that they have the same executions. By Lemmas 1 and 4, z is an 
execution of EC iff z is an execution of A such that z|A, is an execution of A; for every 
t € I iff z is an execution of CE. Thus, EC and CE have the same executions, and 
hence are equal. 0 


Composition of Schedule Modules 


We now define the composition of schedule modules. The composition [];<; 5; of com- 
patible schedule modules {S; : 1 € I} is defined to be the schedule module with action 
signature [],¢7 81g(S;), and schedules y such that y|S; is a schedule of S, for every 1 € I. 
This composition is defined so that the following result holds. 


Lemma 6: For all compatible execution modules {E; : 1 € I}, 


Scheds(|] Ei) = [J] Seheds(E;). 
ier ie 


Proof: Let SC = Scheds([]; £;) and CS = []; Scheds(E,). Since SC and CS clearly 
have the same action signatures, we need only show that they have the same schedules. 
Suppose £; is an execution module of an automaton A; for every : € J. Notice that y 
is a schedule of SC iff y is the schedule of an execution z of [],; E;. Lemma 4 implies 
this is the case iff y is the schedule of an execution z of [J]; A; such that z|E; = 2; is an 
execution of E; for every 1 € J. Lemma 2 implies this is the case iff y|E, is the schedule 
of an execution z; of E;. From the definition of schedule module composition we see 
this is the case iff y is a schedule of CS. Thus, SC and CS have the same schedules, 
and hence are equal. O 


In addition, we have the following. 


Lemma 7: For all compatible schedule modules {S; : 1 € J}, 


External(]] S;) = [] Ezternal(S;). 


fel el 


Proof: Let S = J]; 5;, and let EC = External([]; S;) and CE = []; Ezternal(S;). Since 
the schedule modules S; are compatible, int(S;) M acts(S;) = @ for all i # 7. That is, 
the internal actions of each schedule module are disjoint from the actions of the others. 
With this observation, it follows from the definition of action signature composition 
that EC and CE have the same action signature. We need only show they have the 
same schedules. If y is a schedule of EC, then y = y’|ezt(S) for some schedule y/ 
of S. Since y’|S; is a schedule of S;, y|Ezternal(S,;) = y'|Ezternal(S;) is a schedule of 
External(S;), and hence y is a schedule of CE. Conversely, suppose y is a schedule of 
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CE. Then y|Ezternal(S;) = y;|eat(S;) for some schedule y; of S;. Suppose y = 7172. 
Let us write y; = afi a} .. . where ai is a (possibly empty) sequence of internal gctions 
of S;, and (% is x; if 7; is an external action of 5; and the empty string otherwise. Let 
y’ = Yo™1771-.. where 4; is an arbitrary interleaving of the actions appearing in the ai. 
Then y’ isa sequcnce of actions of S such that y’'|S; = y; is a schedule of S;, so y’ ay a 
schedule of S. Since y = y’|ezt(S), y is a schedule of EC. O 


Lemmas 5, 6, and 7 can be summarized as follows. 


Corollary 8: Let A denote the class of automata, € denote the class of execution 
modules, and §$ denote the class of schedule modules. The following diagram commutes: 


A Execs Scheds External 
II II IT IT 
A Execs Scheds External 


One important consequence of Corollary 8 is the following result, which says that 
the (unfair) behavior of a composition is the composition of its components’ (unfair) 
behaviors. 


Lemma 9: Ubeh([] O;) = [] Ubeh(O;) for all compatible objects {O; :1 € J}. 
ier iez 


It is now possible to see that composition satisfies a number of natural axioms. We 
note that the following result is an immediate consequence of the definition of schedule 
module composition. 


Lemma 10: Suppose S = [];5;, T=[],7;, U =[];Ui, and V = [],; Vi where the S;, 
T;, U;, and V; are schedule modules. 


1. S-T=T-S. 
2. (§-T)-U=S-(T-U). 


3. If S = T and U = V, then S-U =T-V whenever the compositions S -U and 
T -V are defined. 


As a consequence of Lemmas 9 and 10, we have the following. 
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Lemma 11: Suppose O = [J;0;, P=[f],2, Q@ = 19, and R = J]; A; where 
the O;, P;, Q;, and R, are objects. 


1.0-P "4" p.o. 
2. (0-P)-Q“E" 0.(P-Q). 


3. Ifo “£*" P and Q “E* R, then O-Q “£*" P. R whenever the compositions 
O-Q and P- RB are defined. 


Proof: Recall that O- P “£"" P.O iff the external schedule modules Ubeh(O- P) and 
Ubeh(P -O) are equal. By Lemma 9 we see that Ubeh(O- P) = Ubeh(O) - Ubeh(P) and 
Ubeh(P +O) = Ubeh(P) - Ubeh(O). However, Lemma 10 implies that these schedule 
modules are equal. Therefore, O - P wil D.O. The remaining parts are similar. (] 


Conditions 1 and 2 say that composition is commutative and associative up to 
equivalence. Condition 3 says that composition is a almost congruence with respect to" 
composition. However, since the external behavior of O and Q contains no information 
about the internal actions of O and Q, their external behaviors do not determine 
whether they are compatible, and hence whether their composition is defined. Thus, 
equivalence is not quite a congruence. We call an equivalence satisfying condition 3 a 
weak congruence. Notice that this weakness is due only to conflicting internal actions 
names, actions not affecting the external behavior of an object. In Section 2.1.3 we will 
see how to perform a syntactic renaming of internal action names to avoid this conflict 
without affecting the external behavior of the object. This is reminiscent of variable 
renaming to avoid conflict during substitution in predicate calculus. 


2.1.2 Action Hiding 


Recall that composition does not hide actions modeling interprocess communication: 
In particular, if + is an output action of A and an input action of B modeling com- 
munication from A to B, then * becomes an (external) output action of A- B. Since 
this communication is really internal to the system A - B, we would like to be able to 
hide x from external view, to transform x into an internal action of A- B. 


Given an object O and a set of actions L, we define the object Hides(O) to be the 
object differing from O only in that 


1. in(Hidey(O)) = in(O) — Z, 
2. out(Hides(O)) = out(O) — X, and 
3. int(Hidesy(O)) = int(O) U (acts(O) NX). 
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Since the hiding operation modifies only the action signature of an object (without 
modifying its executions or schedules), we have the following: 


Lemma 12: For all automata A, execution modules E, schedule modules S, and sets 
of actions L, 


1. Execs(Hides(A)) = Hidey(Ezecs(A)) 
2. Scheds(Hidey(E)) = Hidey(Scheds(E)) 
3. External(Hides(S)) = External(Hides(Ezternal(S))) 


Proof: Parts 1 and 2 are immediate from the definition of the hiding operation. Part 3 
follows from the fact that y|(ezt(S) —£) = (y|ezt(S))|(ezt(S) —X) for every schedule y. 
CJ 


As a corollary of Lemma 12, we have the following: 


Corollary 13: Let A denote the class of automata, € denote the class of execution 
modules, and $ denote the class of schedule modules. The following diagram commutes: 


A Ezecs Scheds External 


S 
Edam 
Hide Hiden Hiden S 
A Execs Scheds External S He zternal 


Suppose {O; : 1 € I} are compatible objects, and consider their composition O. 
Suppose that w is an action of O; not shared by O; for every : # 7. Intuitively, if 7 
models some communication internal to the system component modeled by O,, then 
whether x is hidden before or after forming the composition O should not affect the 
resulting object. This intuition is formalized in the following result. 
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Lemma 14: Let {O; : 1 € I} be acollection of compatible objects, and let {Z,; : 1 € I} 
be a collection of sets of actions. If acts(O;) and Lj are disjoint for all 1 # 7, then 
Hidew,z, (I O%) = [] Aidey,(O;). 

i€ ier 


Proof: Let HC = Hideu,r,(T];O;) and CH = J], Hidey,(O,). First, we claim that 
the composition HC is defined iff CH is defined. Since for all 1 # 7 the intersection 
acts(O;) NZ; is empty, for all 4 7 we have 


out(O;) MN out(O;) = (out(O;) — L;) NM (out(O;) — X;) 
out (Hides, (O;)) a out (Hides, (0;)) 


and 


int(O;) M acts(O;) = [int(O;) U (LZ, acts(O,))| M [acts(O;) — ;} 
int (Hidey,(O;,)) N acts( Hides ,(O;)). 


It follows that the objects O; are compatible iff the objects Hidey,(O,) are compatible, 
and hence that HC is defined iff CH is defined. 


Next, we claim that HC and CH have the same action signatures, and it will follow 
that HC and Cd are equal. Notice that 


in(HC) = in(IL 0%) ~ Us 

= (Uin(o,) -— U out(0,)) - UX 
iel jel hel 

= (Um(o) —-U,) — (U out(o,) - U 5,) 
ier jel tel jel 

= J (in(O;) — X) = |) (out(O;) ~ £5) 
tel jel 

= (J im(Hides,(O;)) — (J out( Hider, (O;)) 
tel gel 


in([] Hider,(O,)) = in(CH). 
ier 
The fourth equality holds since acts(O;) MZ; is empty for all s # j. Similar arguments 


show that out(HC) = out(CH) and int(HC) = int(CH). Therefore, HC and CH 
have the same action signature, and hence are equal. 2 


2.1.3 Action Renaming 


Our definition of composition makes the names of actions quite important. In particu- 
lar, the notion of object compatibility depends entirely on the names of actions shared 
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by the objects. In this section, we define an operation that renames actions. With this 
operation, objects can be made compatible by renaming conflicting actions. 


An action mapping f is an injective mapping between sets of actions. Such a 
mapping is said to be applicable to an object O if the domain of f contains the ac- 
tions of O. Action mappings are extended to objects in the obvious way. If the 
action mapping f is applicable to an automaton A, then the automaton f(A) is 
the automaton with the states and start states of A; with the input, output, and 
internal actions f(in(A)), f(out(A)), and f(int(A)), respectively; with the transi- 
tion relation {(a, f(x),a') : (a,x,a’) € steps(A)}; and with the equivalence relation 
{(f(*), f(*)) : (x, 2’) € part(A)}. Since f is injective, the partition of the locally- 
controlled actions of f(A) is guaranteed to be an equivalence relation. Objects f(O) 
are defined similarly for other types of objects. Such an object f(O) is said to be a 
renaming of O. Since renaming affects only action names, the following result is easy 
to see. 


Lemma 15: Let f be an action mapping applicable to the automaton A, the execution 
module FE, and the schedule module S. 


1. Ezecs(f(A)) = f(Ezxees(A)) 
2. Scheds(f(E)) = f(Scheds(E)) 
3. External(f(S)) = f(Ezternal(S)) 


In addition, since action mappings are injective, it is easy to see that actions may 
be hidden before or after renaming: 


Lemma 16: Hideysy)(f(O)) = f(Hides(O)) for any object O and applicable action 
mapping f. 


Let us consider how renaming interacts with composition. Suppose an action map- 
ping f; is applicable to the object O; for every t € J. First, notice that if each f; maps 
some output action x; of O; to the action 7, then the f;(O;) are incompatible; and 
Il; f:(Ox) is not be defined even though []; O; may be. Furthermore, if each f; maps an 
action x to a different action x;, then executions of [],; f;(O;) may have no relationship 
to the executions of []; O; since the objects f;(O;) may no longer be required to syn- 
chronize on the actions x;. We are therefore led to define a collection {f; : 1 € I} of 
action mappings to be compatible if for all actions 7; and 2; we have f,;(7;) = f;(7;) iff 
™; = 7;. We define their composition f = |], f; to be the action mapping having as its 
domain the union of the domains of the f;, and mapping the action x to fj(x) if is 
in the domain of f;. The fact that the f; are compatible ensures that f is well-defined. 
It is obvious that if each f; is applicable to an object O,;, then f is applicable to their 
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composition. In addition, the following result verifies that the renaming of such objects 
may occur either before or after the formation of their composition without affecting 
the resulting object. 


Lemma 17: Let {O; : 1 € I} be compatible objects, and let {f; : 1 € I} be compatible 
action mappings. If f; is applicable to O; for every 1 € J, then ([]_ f:)(II Ox) = I fi(O,). 
ier ie ie 


Proof: We prove the result for automata A;; the proofs for other types of objects are 
similar. Let f = []; fi, A = I], 4s, and A’ = J]; fi(A;). We show that f(A) is defined 
iff A’ is defined, and that in this case f(A) = A’. To do so, we must verify the following: 
(i) that the A; are compatible iff the f;(A;) are compatible, (ii) that f(A) and A’ have 
the same states and start states, (iii) that f(A) and A’ have the same action signature, 
(iv) that f(A) and A’ have the same transition relation, and (v) that f(A) and A’ have 
the same partition of locally-controlled actions. Since the f; are injective mappings 
such that f,(m;) = f;(x;) iff 1; = 2;, the only nontrivial part of this proof to check is. 
part (iv). Suppose that (a,7,a’) is a step of f(A). For some action o we must have 
that (a,¢,a') is a step of A, and that f(c) = . Furthermore, for each 1, the action 0 
is an action of A, iff x is an action of f;(A;). If x is an action of f;(A,;), then o is 
an action of A;, so (a|A;,0,a'|A,) is a step of A; and (a|f;(A;),7,a\f;(A;)) is a step of 
f(A;). If + is not an action of f;(A;), then o is not an action of A;, so a|A; = a'|A; 
and a|f;(A;) = @'|f;(A;). In either case, (a,7,a’) is a step of A’ = [], f;(Ai). A similar 
argument shows that if (a,x, a’) is a step of A’, then it is a step of f(A). It follows that 
f(A) and A’ have the same transition relation, and hence are equal. O 


2.1.4 Remarks 


Since the definitions given so far have been independent of such considerations, we 
have chosen to ignore until this point issues of cardinality that appear in most mod- 
els of computation. For example, we have not restricted our model to automata with 
countable sets of states and actions, and hence to countable nondeterminism. Fur- 
thermore, we have not restricted our theory to the composition of a finite (or even 
countable) number of automata. While these are natural restrictions (and all of the 
results presented thus far still hold when these restrictions are imposed), we note that 
Lynch and Merritt have made effective use of the composition of a countable number 
of automata in [LM86]. In the remainder of this thesis, we restrict our attention to 
automata modeling systems with a countable number of components. In particular, we 
restrict our attention to countable compositions, and to automata A for which part (A) 
partitions A’s locally-controlled actions into a countable number of equivalence classes. 
This restriction becomes relevant in the following section where we define the notion 
of fair computation. 
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2.2 Fairness 


Fair computation is of central importance to distributed computation. The mutual 
exclusion problem, for example, has been formulated in [EM72] with the “no lockout” 
condition that if every process is allowed to take steps infinitely often, then every 
process trying to enter its critical region will eventually do so. That is, during fair 
computation, every process wishing to enter its critical region will eventually do so. 
More generally, the specification of a distributed system typically includes conditions 
of the form “if condition P holds, then eventually condition Q will hold.” The ability 
of a process to satisfy such conditions clearly depends on fair computation. In this 
section we show how fair computation can be described in our model, and we show 
how fair computation induces an interesting equivalence of automata. 


2.2.1 Fair Executions 


As previously mentioned, computation in a system of processes is said to be fair if 
every process is given the chance to make computational progress infinitely often. The 
phrase “given the chance” is important, since a process may not be in a position 
to make progress every time it is given the chance. Recall that associated with an 
automaton A is a partition part(A) of its locally-controlled actions. Intuitively, each 
class of this partition consists of the locally-controlled action of a process in the system 
being modeled by A. A fatr ezecution of an automaton A is defined to be an execution x 
such that the following conditions hold for each class C of part (A): 


1. If z is a finite execution, then no action of C is enabled from the final state of z. 


2. If z is an infinite execution, then either actions from C appear infinitely often 
in z, or states from which no action of C is enabled appear infinitely often in z. 


These conditions may be interpreted as follows. If z is finite, then computation in the 
system has halted since no process is able to take another step. If z is infinite, then 
every process has been given the chance to take a step infinitely often, although it may 
be that some process was unable to make computational progress every time it was 
given the chance to do so. Notice that this definition of fairness is essentially what is 
called weak fairness in the literature (see [Fra86], for example). As mentioned in the 
introduction, however, our definition is different in an important way in that it takes 
into consideration the notion of one process controlling the performance of an action. 
In particular, it is possible for an (input) action to be continuously enabled, and yet 
never be performed. We note in passing that our notion of fairness defines the notion 
of a finite fair computation without the usual requirement that finite computations be 
extended in some trivial way to infinite computations. 
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The set fair(A) is the set of fair executions of the automaton A, and Fair(A) is the 
execution module of A having fair(A) as its set of executions. 


One simple consequence of this definition of fair executions is the following. 


Lemma 18: If z is a finite execution of an automaton A, then z can be extended to 
a fair execution r7,a,... of A (in which every 7; is a locally-controlled action of A). 


Proof: Let f be a function mapping the natural numbers to the classes of part (A), 
with the property that every class of part(A) appears in the range of f infinitely often. 
There is an execution z’ = r7,a;... of A with the property that 7; is an action from the 
class f() if such and action is enabled from a;_;, and an arbitrary locally-controlled 
action of A otherwise. (If from some state a;_,; no locally-controlled action of A is 
enabled, then z’ is a finite execution ending in state a;_;.) The execution 2’ is a fair 
execution of A. CL) 


More important, however, is the next lemma which says that the fair executions of 
a composition are a composition of the fair executions of its components. It is for the 
sake of this result that we associate a partition of an automaton’s locally-controlled 
actions with an automaton. 


Lemma 19: Fair([] A;) = [] Fair(A;) for all compatible automata {A; : # € I}. 
ier ier 


Proof: Let FC = Fair({[]; A;) and CF = [|]; Fair(A;). Since both are execution 
modules of A = J]; A;, both have the same states and action signature. We need only 
show that they have the same executions. First, however, notice that since the A; 
are compatible, their locally-controlled actions are disjoint. Furthermore, notice that 
each A; is input-enabled. It follows that each A; determines when its locally-controlled 
actions are enabled in the composition A: If x is a locally-controlled action of A; and a 
is a state of A, then x is enabled from a in A iff x is enabled from a|A; in A;. 


Suppose z is a fair execution of A, and let us show that z is an execution of CF. 
We must show that 2|A; is a fair execution of A; for all t. Let C be a class of locally- 
controlled actions of A;, and hence a class of A. Suppose = is finite. Since z is a fair 
execution of A, no action of C is enabled in A from the final state a of z, and hence 
no action of C is enabled in A; from the final state a|A; of z|A;. Suppose z is infinite. 
If actions from C appear infinitely often in z, they do so in z|A;. On the other hand, 
suppose states appear infinitely often in z from which no action of C is enabled in A. 
It follows that either z|A; is finite and no action of C is enabled from the final state of 
z|A; in Aj, or else infinitely many states of A; appear in z|A, from which no action of C 
is enabled. In any case, z|A; is a fair execution of A;. It follows that z is an execution 
of CF. 
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Conversely, suppose z is an execution of CF, and let us show that z is a fair 
execution of A. Let C be a class of locally-controlled actions of A, and therefore a class 
of A; for some s. Since z is an execution of CF, the execution z|A, is a fair execution 
of A;. Suppose z is finite, and therefore that z/A, is finite. Since z|A, is fair, no action 
of C is enabled from the final state of z|A;, and hence no action of C is enabled from 
the final state of z. Suppose z is infinite. If actions from C appear infinitely often 
in z|A;, the same is true of z. If states appear infinitely often in z|A; from which no 
action of C is enabled, the same is true in z. However, z|A; may be finite. In this 
case, no action of C is enabled from the final state of z|A,. Since z is infinite, there is 
a state appearing in z after which no action of C is ever enabled. In any case, z must 
be a fair execution of A. It follows that FC = CF. 0 


2.2.2 Fair Equivalence 


In Section 2.1 we defined a notion of equivalence based on the external behavior of 
an object. We now define a similar notion of equivalence based on fair external be- 
havior. The fair behavior of an automaton A, denoted by Fbeh(A), is defined to be 
the schedule module Ezternal(Fatr(A)). We extend this definition to objects of other 
types (execution modules and schedule modules) by setting Fbeh(O) = Ubeh(O). It is 
convenient to denote the set of schedules of Fbeh(O) by fbeh(O), for any object O. In 
light of Corollary 8 and Lemma 19, we see that the fair behavior of a composition is 
the composition of the fair behavior of its components. 


Lemma 20: Foeh( I] 0;) = I] Fbeh(O;) for compatible objects {O; : ¢ € I}. 
ie ie 


We say that two objects O and O’ are fairly equivalent, denoted O fair o , if they 
have the same fair behavior; that is, if Fbeh(O) = Fbeh(O'). In light of Lemmas 10 
and 20, fair equivalence satisfies the axioms stated for unfair equivalence in Lemma 11. 


Lemma 21: Suppose O = [];0;, P=J[I;R, @ = 1,9, and R = I]; R where 
the O,, P;, Q;, and R; are objects. 


1.0-P‘! P.o. 
2. (O-P)-Q’2"0-(P-Q). 


3. If 0/2" P and Q far R, then O-Q !#" Dp. R whenever the compositions O -Q 
and P : R are defined. 
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Figure 2.2: The importance of the partition of locally-controlled actions. 


Thus, composition is commutative and associative up to fair equivalence, and fair 
equivalence is a weak congruence with respect to composition. With this we conclude 
that discussion of fairness directly related to program verification. In the remainder of 
this section we consider several interesting questions about how fairness is modeled in 
our model. 


2.2.3 Fairness and System Decomposition 


Having seen the definition of a fair execution, the role of the equivalence relation 
part(A) associated with an automaton A is clear: The automaton models a system, 
and the locally-controlled actions of each system component form a separate class of 
the partition. It is worth considering, however, whether this partition is really of any 
importance. We claim that if relationships such as those stated in Lemma 20 are of 
importance (and we think they are), then the information about the system structure 
encoded in the partition of an automaton’s locally-controlled actions must be retained. 
Suppose for a moment that we do away with the partition, so that all we know about 
an automaton’s locally-controlled action is whether it is an internal or output action. 
Consider the automata A and B given in Figure 2.2, and consider their composition 
A+B. Here a is an input action, and § and ¥ are output actions. In both automata A 
and B, the execution with the infinite sequence of a’s as its schedule may be considered 
a fair execution since infinitely often each automaton passes through a state from which 
no locally-controlled action (either 6 or y) is enabled. In the composition, however, a 
locally-controlled action is enabled from every state through which such an execution 
must pass, and yet none of these actions appear in the execution. This execution cannot 
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be considered a fair execution of the system since the system is never allowed to make 
progress, even though it is able to do so at each stage of the execution. If, on the other 
hand, we recognize that @ and ¥ are output actions of separate system components, we 
see that infinitely often each component passes through a state from which none of its 
locally-controlled actions is enabled. We therefore conclude that this ss an execution of 
the system that is fair to all components, and hence can be considered a fair execution 
of the system. The partition of locally-controlled actions therefore seems to be an 
important component of an input-output automaton. 


It is conceivable, however, that an automaton’s actions can be partitioned in such a 
way that it is impossible for the automaton to model a system whose components have 
as their locally-controlled actions one class of the partition. It therefore seems possible 
for our intuitive understanding of an automaton’s partition of its locally-controlled 
actions to be violated. Let us say that an automaton A is primitive if part(A) consists 
of a single class. Intuitively, such an automaton can model only an “atomic” system 
component. It would be nice to know that every automaton A is (fairly) equivalent 
to a composition of primitive automata, where the locally-controlled actions of each 
primitive automaton form a class of A’s partition. This would in effect be saying that 
every automaton does model a system in a way satisfying our intuition. What we can 
prove is the following. An automaton is said to be deterministic if it has one start 
state, and for every action 7 there is at most one x-step from every state. 


Lemma 22: Let A be an automaton whose equivalence relation part (A) partitions its 
locally-controlled actions into the classes {C; : 1 € I}. If A is deterministic, then there 
are primitive automata A; such that C; is the set of locally-controlled actions of A,, 
and A ‘2’ Hidena(a)( II As). 


Proof: Since A‘ Hidejne(a)(A’) where A’ is the automaton differing from A only in 
that the internal actions of A are output actions of A’, we may assume without loss of 
generality that A has no internal actions, and show that A tar I]; A;» Let A; be the 
primitive automaton obtained from A as follows. First, set in(A,;) = acts(A) — C; and 
out(A;) = C;. Second, add to A; a dead state d. Finally, to ensure that A, is input- 
enabled, if x is an input action that is not enabled from a state a, add the transition 
a + d from a to the dead state d. Let B = J], A;. We claim that A 2" B. 


Suppose z is a fair execution of A. Since z is also an execution of each A;, there is 
an execution y of B such that y|A; = z for every 1. We claim that y is a fair execution 
of B. If actions from C; appear infinitely often in z, then the same is true of y. On 
the other hand, suppose that 7 is an action of C; that is not enabled from a state a 
of A. Then = is an (output) action of A; that is not enabled from the state a in A;, and 
hence not from the state {a} in B. It follows that if z is finite and no action from C; is 
enabled from the final state of z, then the same is true of y; and that if z is infinite and 


36 


there are infinitely many states appearing in z from which no action of C, is enabled, 
then the same is true of y. Therefore, y is a fair execution of B. 


Conversely, suppose y is a fair execution of B. We claim that z = yA, is a fair 
execution of A for every 1. We will soon show that if 6 is a reachable state of B, then 
all components 6|A; of 6 are equal, and equal to a state other than d. From this it 
will follow that all y|A; are equal. Furthermore, since z = y|A;, the state d must not 
appear in z. Since transitions to d were the only transitions added in the construction 
of A;, z is an execution of A. Furthermore, since z is fair in A;, either z is finite and no 
action of C; is enabled from the final state of z; or z is infinite and either actions of C; 
appear infinitely often in z, or states appear infinitely often in z from which no action 
of C, is enabled. Since this is true for every class C,, x is must be a fair execution of A. 


We now proceed by induction on the length @ of an execution required to reach 6 to 
show that 6|A,; = 6|A; # d for all s and 7. Since A has a single start state, each A; has 
the same (unique) start state, and the case of ¢ = 0 is trivial. Suppose 4 > 0 and the 
inductive hypothesis holds for £— 1. Suppose 6 is reachable by an execution of length @ 
whose last transition is b’ > 6. Since 6’ is reachable by an execution of length é— 1, 
the inductive hypothesis implies that ’|A; = b'|A; # d for all and 7. Since x is either 
an input action of A or an output action of A (and hence of some A,), there must be 
an automaton A, for which no transition 6'|A; +, d was added during its construction. 
It follows that 6'|A; —> 6|A; must be a transition of A, and hence that no dead state 
transition was added from 6/|A; during the construction of any A;. Therefore, every 
step b'|A; > b|A; is a step of A. Since A is deterministic, there is only one such step, 
so 6|A; = b|A; # d for all ¢ and 7. C) 


This result says that our intuition (our understanding of an automaton’s partition 
of its locally-controlled actions) is satisfied by a very restricted class of automata. It 
does not seem to be true, however, for arbitrary automata (although Lemma 22 does 
hold for arbitrary automata if fair equivalence is replaced by unfair equivalence, the 
proof of this using the same construction as in the proof of Lemma 22). The reason the 
construction given above will not work for nondeterministic automata is clear: The ex- 
istence of nondeterminism allows the components to diverge during computation. Each 
component may then pass through states from which none of its locally-controlled ac- 
tions are enabled, from which it follows that no locally-controlled actions appear in the 
executions generated by any of the components. Since, however, each component may 
pass through states from which all locally-controlled actions of all remaining compo- 
nents are always enabled, none of the executions generated by any of the components 
are fair executions of the original automaton A, whose classes are the output actions of 
the component automata. What is obviously required is a coordinator or scheduler S to 
ensure that all automata choose the same transition at every step. With this intuition 
in mind, we now prepare to show the following. 


Theorem 23: Let A be an automaton whose equivalence relation part (A) partitions its 
locally-controlled actions into the classes {C; : 1 € I}. There are primitive automata A; 
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and S such that C; is the set of locally-controlled actions of A,;, = is the set of locally- 
controlled actions of S, and A ‘= Hidesnayur(I] Ai: 5). 
ier 


The primitive automata A; used in this construction are essentially the primitive 
automata used in the proof of Lemma 22. However, when the A; perform an action, the 
scheduler S must be able to direct all of them to take the same step. These directions 
take the form of certain input actions of the A;, where the performance of such an action 
by the scheduler tells the component automata which transition they are supposed to 
make. We add these actions to the A; (although initially as internal actions) with the 
following result. 


Lemma 24: For every automaton A, there is a deterministic automaton B such that 


A ‘2 B. The locally-controlled actions of B are partitioned into the classes of A, 
together with an additional class © of internal actions. 


Proof: For ease of exposition, we construct a nondeterministic automaton B, and then 
show how it can be transformed into an equivalent deterministic automaton. The states 
of B are of the form (a,a) where a is a state and a is a (possibly empty) sequence of 
actions. The start state of B is (s,¢), where s is a distinguished state (not a state of A) 
and ¢ is the empty sequence of actions. The states of B are (a, a) and (8, a), where a is 
a state of A and a is a (possibly empty) sequence of actions of A. The action signature 
and partition of B are precisely those of A, except that an additional scheduling action x 
(an internal action) forms its own class of B’s partition. The transitions of B from a 
state (a,a), where a is a state of A, are as follows: 


(a,a) > (a',c)inB iff a+a'inA 
(a,a) +(a,ac)in B iff aa’ in A for some a’ 


That is, + determines what transitions A actually makes from the state a when the 
sequence of actions a is actually performed. All other actions are simply recorded as 
actions to be performed by A at a later time. The transitions of B from a state (s, a) 
are as follows: 


(s,a) ~ (a,€) in B iff again A for some start state ao 
(s,a) + (s,ac) in B iff o is an input action of A 


In this case, only input actions and 7 are enabled from a state of the form (s,a). In 
this way, fair computation will guarantee that x is eventually performed, and hence 
that an initial state is chosen for A. Thus, the scheduling action 7 chooses the initial 


state of A, as well as the steps taken by A during computation. We claim that A far B. 
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Suppose that A’s locally-controlled actions are partitioned into the classes {C; : 1 € I}. 
These classes together with the class {7} are the classes of B. 


Let z be a fair execution of A. Let y be the execution of B obtained by replacing 
each transition a > a’ of z by the transitions (a,c) > (a,c) > (a',e), followed by 
the infinite sequence of transitions (a,<) + (a,¢) “+ --- in the case that z is a finite 
execution ending in the state a. Suppose z is finite. Since z is fair, no locally-controlled 
action is enabled in A from the final state a of z. It follows that no locally-controlled 
action of B is enabled from any of the infinite occurrences of (a,¢) in y, except for x 
which occurs infinitely often. Hence, y is a fair execution of B. Conversely, suppose 
that z is infinite. Since z is fair, for each class C; either actions from C; appear infinitely 
often in 2, or from infinitely many states appearing in z no action from C; is enabled. 
In the first case, actions from C; appear infinitely often in y. In the second case, since 
an action o is enabled from a state a of A iff it is enabled from (a,e¢) in B, infinitely 
many states appear in y from which no action of C; is enabled. Since, in addition, 7 
appears infinitely often in the execution, y must be a fair execution of B. 


Conversely, let y be a fair execution of B. From the definition of B we see that 
if (a,e) 4 (a,01)--- 3 (a,0,-+-on) — (a’,€) is a sequence of transitions in B, then 
a “4 a,--- “3 a! is a sequence of transitions of A. In addition, if (s,€) “ (s,o,)--- 3 
(8,01°++On) >» (a,€) is a sequence of transitions in B, then a9 “4 a,--: 3 a isa 
sequence of transitions of A for some start state ao of A. Let z be the execution 
of A obtained by replacing every such sequence in y by the corresponding sequence of 
transitions of A. Since y is fair, the action must appear infinitely often in y, and 
hence y must be infinite. If actions from C; appear infinitely often in y, then the same 
is true in z. If not, then there are infinitely many states appearing in y from which no 
action of C; is enabled. Notice that if an action o other than 7 is not enabled from 
from the state (a, a) in B, then for all states a’ of A such that a > a’ it must be that o 
is not enabled from a’. It follows that either z is finite and no action of C; is enabled 
from the final state of z, or there are infinitely many states appearing in z from which 
no action of C; is enabled. In either case, z must be a fair execution of A. 


We have just shown that A far B. However, we are not yet done since B is not 
yet deterministic: There are potentially many 7-steps from every state of B. However, 
we can assign to each x-step a unique identifier, and tag the 7 labeling the step with 
this identifier. Replacing the action x with the set L of newly-tagged x’s, it is easy 
to see that this automaton is fairly equivalent to B, and hence also to A. Since this 
automaton is a deterministic automaton (with an extra class © of internal actions), we 
are done. 0 


We are now able to prove Theorem 23. 


Proof of Theorem 238: Given the automaton A, construct the automaton B of 
Lemma 24. The automaton B is fairly equivalent to A, and its locally-controlled 
actions are partitioned into the same classes as those into which A’s actions are par- 
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Figure 2.3: Fair equivalence and unfair equivalence are incomparable. 


titioned, together with an additional class £ of internal actions. Furthermore, B is a 
deterministic automaton. Lemma 22 says there are primitive automata A; and S with 
local(A;) = C; and local(S) = © such that B (and hence 4A) is fairly equivalent to 
Aideing(B) (1; A; i S), which is just Hideine(ayus (Tl; A; : S). Oj 


2.2.4 Comparing Fair and Unfair Equivalence 


Having defined two types of equivalence, fair equivalence and unfair equivalence, it is 
natural to ask how they are related. Since Fbeh(O) = Ubeh(O) when O is an execution 
module or schedule module, fair and unfair equivalence are identical for execution 
modules and schedule modules. For automata, however, they are incomparable. 


Consider, for example, the automata of Figure 2.3. The (primitive) automata A 
and B each have an input action a and an output action @. The unfair behavior of 
both A and B consists of all sequences of a and §, so A and B are unfairly equivalent. 
The fair behavior of A, however, includes the infinite sequence of a’s. Since the fair 
behavior of B does not, A and B are fairly inequivalent. On the other hand, C and D are 


40 


two (nonprimitive) automata with output actions a and (7, each forming a separate class 
in the partition of the locally-controlled actions. The fair behavior of C and D consist 
of finite sequences of a’s followed by a @ and an infinite sequence of a’s, so C and D 
are fairly equivalent. The unfair behavior of C, however, includes the infinite sequence 
of a’s. Since the unfair behavior of D does not, C and D are unfairly inequivalent. 


Thus, in general, fair equivalence and unfair equivalence are incomparable. The 
following lemma, however, indicates that fair equivalence implies unfair equivalence in 
the case of primitive automata. Since the primitive automata A and B of Figure 2.3 are 
unfairly equivalent but not fairly equivalent, we see that fair equivalence is a stronger 
equivalence that unfair equivalence in the case of primitive automata. 


Lemma 25: Let A and B be two primitive automata. If A and B are fairly equivalent, 
then A and B are unfairly equivalent. 


Proof: It is enough to check that scheds(A)|ezt(A) = scheds(B)|ezt(B). Suppose z. 
is an execution of A. If an infinite number of locally-controlled actions appear in z, 
then since A is a primitive automaton (with a single class of locally-controlled ac- 
tions), z is a fair execution of A. Since A and B are fairly equivalent, there is a fair 
execution y of B such that sched(z)|ezt(A) = sched(y)|ezt(B). On the other hand, 
if only a finite number of locally-controlled actions appear in z, then we may write 
z = z'z" where z’ is a finite execution of A, and every locally-controlled action ap- 
pearing in z appears in z’. By Lemma 18, the finite execution x’ can be extended 
to a fair execution z of A. Since A and B are fairly equivalent there is a fair exe- 
cution y of B such that sched(z)|ezt(A) = sched(y)|ezt(B). Thus, there is a finite 
execution y’ of B, a prefix of y, such that sched(z’)\ext(A) = sched(y’)\ezt(B). Since B 
is input enabled and no locally-controlled action appears in z after z’, y’ may be ex- 
tended to an execution y” of B such that sched(xz)|ezt(A) = sched(y")|ezt(B). Thus, 
scheds(A)|ezt(A) C scheds(B)|ext(B). Since the opposite containment follows by a 
symmetric argument, we are done. OC 


2.3 Hierarchical Correctness Proofs 


The problem motivating this thesis is the construction of hierarchical correctness proofs 
for distributed algorithms. We have already mentioned in the introduction how such a 
proof might be constructed. First, a sequence of models O,,...,O, are defined, objects 
of some type modeling the algorithm at decreasing levels of abstraction. Each model O; 
is then shown to “simulate” O,_, in some appropriate sense of the word “simulate.” In 
such a proof, each O;.,; can be viewed as the statement of a problem O;, is required to 
solve. O; may be said to solve the problem specified by O,_, if every behavior of O; 
is a behavior of O;.;. O; solves the problem specified by O;., in the sense that every 
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correctness condition satisfied by each behavior of O;_, is also satisfied by each behavior 
of O;. However, as previously mentioned, the satisfaction of certain liveness conditions 
depends on fair computation. We therefore require only that every fair behavior of O, 
be a fair behavior of O,_,. That is, O, is said to satisfy O,_; if fbeh(O;) C fbeh(O,-1). 
We also require that O; and O,_; have the same external action signature. 


Notice, however, that this notion of correctness is not completely satisfactory. In 
particular, a schedule module O, with no schedules trivially satisfies every problem O;_, 
(with the same external action signature). Furthermore, since the schedules of O; are 
allowed to be arbitrary sequences of actions, it is conceivable that they may encode 
information allowing the solution of undecidable problems, and hence not be behaviors 
of an implementable system. In an attempt to avoid such anomalies, we say that the 
object O;_1 is implementable if there is an automaton satisfying O;_,. The object O,_, is 
implementable in the sense that there is a system satisfying every correctness condition 
satisfied by O;-,;. Furthermore, since O;- is satisfied by an automaton, and since 
every automaton is input-enabled, the object O;_, must describe a response to every 
possible pattern of input. That is, the behavior of O,_, is nontrivial. We say that O;-, 
solves O; if O;-, is an implementable object satisfying O,;. In the context of constructing 
hierarchical correctness proofs, such a proof consists of a sequence O;,...,O, of objects, 
and the verification that each O, solves O;_}. 


Clearly, the notion of satisfaction is the basis of each of these definitions. The 
remainder of this section concerns techniques for verifying that one object satisfies 
another. Two properties of satisfaction are very easy to see. The first is that satisfaction 
is transitive, and a weak congruence with respect to composition. 


Lemma 26: Consider the objects O,;, P;, and Q;, for 1 € I. 
1. If O; satisfies P; and P; satisfies Q,;, then O, satisfies Q;. 


2. If O; satisfies P; for every : € J, then [], O; satisfies []; P; whenever the composi- 
tions []; O; and J]; P; are defined. 


Proof: The proof of the first part is immediate from the definition of satisfaction. 
The second part requires some proof. As a result of Corollary 8, the external action 
signature of []; O; is the composition of the external action signatures of the O;, and 
similarly for J]; Pj. Since O; and P, have the same external action signature for all 
t € I, so do J], O; and []; P. Since fbeh(O;) C fbeh(P,) for all + € J, it follows by 
Lemma 20 that fbeh(I]; O,;) C foeh([]; P;). Therefore, []; O; satisfies [], P;. | 


A second property of satisfaction is its invariance under action renaming. 


Lemma 27: Let f be an action mapping applicable to the objects O and P. If O 
satisfies P, then f(O) satisfies f(P). 
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Proof: Since O and P have the same external action signature and since f is injective, 
f(O) and f(P) have the same external action signature. Using Lemma 15 we see that 
fbeh(f(O)) C foeh(f(P)). Thus, f(O) satisfies f(P). | 


While we have repeatedly indicated that our hierarchical correctness proofs consist 
of a sequence of objects O;,...,O, modeling an algorithm at different levels of abstrac- 
tion, our proofs typically have more structure than this. In the proof of Schénhage’s 
resource arbiter (in the next chapter), for example, we actually construct for each level 
of abstraction an automaton A; describing the algorithm at the appropriate level of 
abstraction. This automaton describes as much of the algorithm as can be described 
by its static nature. In particular, the automaton A; encodes all safety conditions re- 
quired. If liveness conditions are required, we construct an execution module E; of A; 
with those executions of A, satisfying the desired liveness conditions. The objects O; 
referred to above are actually the execution modules E;. We note, however, that the 
execution module E, at the lowest level of abstraction typically consists of the fair 
executions of A,. Thus, at the lowest level of abstraction the protocol is completely 
described by an automaton, and we could use the object A, in place of the execution. 
module £, in the correctness proof. Since automata and execution modules are the 
types of objects most frequently used in correctness proofs, in the remainder of this 
section we give techniques for proving the satisfaction of one automaton or execution 
module by another. 


2.3.1 Automaton Satisfaction 


We now describe one method for proving that an automaton A satisfies an automa- 
ton B. This method makes use of the notion of a possibilities mapping, a corre- 
spondence between the states of the two automata that can be used to prove that A 
satisfies B. 


Suppose A and B are automata with the same external action signature, and sup- 
pose A is a mapping from states(A) to the power set of states(B). The mapping h is 
said to be a possibilities mapping from A to B if the following conditions hold: 


1. For every start state a of A, there is a start state 6 of B such that b € h(a). 


2. For every reachable state a of A, every step (a,7,a') of A, and every reachable 
state b € h(a) of B: 


(a) If x € acts(B), then there is a step (b,x, 0’) of B such that  € A(a’). 
(b) If x ¢ acts(B), then 6 € h(a’). 


If a is a state of A, then a state b € h(a) of B is referred to as a possibility for a. 
Informally, 6 is an abstract state corresponding to the less abstract state a. The fact 
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that Ah maps a to a set of possibilities allows for the chance that many abstract states 
may correspond to the single concrete state a. The first condition of a possibilities 
mapping says that every start state of A has as one of its possibilities a start state 
of B. The second condition says that steps A and B preserve possibilities: If 6 is a 
possibility for a, then for every step (a,x,a') of A either 6 is also a possibility for a’, 
or there is a step (b,7,5’) of B with the property that b’ is a possibility for a. This 
definition generalizes the definition of a possibilities mapping used in the context of 
Event-State Algebras in [Lyn83]. It is also reminiscent of the notion of bisimulation 
from CCS presented in [Mil80]. Roughly speaking, a possibilities mapping from A 
to B is a mapping from the states of A to the states of B with the property that if a 
corresponds to 6, and if A can make a transition via the action from a to a’, then B 
can make a transition via the action from 6 to a state 6’ corresponding to a’. Milner’s 
notion of bisimulation is essentially a pair of possibilities mappings, one from A to B 
and another from B to A. 


We now show how to use a possibilities mapping to prove that A satisfies B. Our 
first step is to show how such a mapping relates the executions of A to the executions. 
of B. Given two finite executions z and y of A and B, respectively, we say that y 
finitely corresponds to x under h if sched(y) = sched(x)|B and the final state of y is a 
possibility for the final state of z. In general, if z and y are two executions of A and B, 
we say that y corresponds to x under h if for every finite prefix 2; = ao%,a,...a; of x 
there is a finite prefix y; of y finitely corresponding to z; under A such that y is the limit 
of the y;. Informally, the executions z and y model the same computation at different 
levels of abstraction. Our next result shows that by inductively constructing the y; it 
is always possible to construct such an execution y. 


Lemma 28: Let h be a possibilities mapping from A to B. If z is an execution of A, 
then there is an execution y of B corresponding to x under h. 


Proof: Let x = aom,a;.... For each 1 > 0, let 2; = apm ,a,...a;. We construct the 
finitely corresponding y; inductively, and take y to be the limit of the y;. Since ap is 
a start state of A, the set h(ap) must contain a start state of B, and hence it is easy 
to choose an execution yp finitely corresponding to z» under h. Suppose y;-, finitely 
corresponds to 2;_; under h, and let us construct y,;. First, aj; is a reachable state 
of A, and (a;_1, %;,@;) is a step of A. Second, the final state b of y;-; is a reachable state 
of B in h(a;-;). If 7; € acts(B), then by the definition of A there is a state Y in h(a;) 
such that (b,;,0’) is a step of B. If y; = y;-17,b', then the final state of y; is in h(a;) 
and sched(z;)|B = sched(y,). If x; ¢ acts(B), then from the definition of h we see that 
b€ A(a;). If y; = y-1, then the final state of y; is in h(a;) and sched(z,)|B = sched(y,). 
In either case, y; finitely corresponds to z,; under h. C 


Since each pair of prefixes z; and y; satisfies the condition sched(z;)|B = sched(y;), 
it is easy to see that the executions z and y do so as well. 
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Lemma 29: Let h be a possibilities mapping from A to B. If the execution y of B 
corresponds to the execution z of A under h, then sched(z)|B = sched(y). 


Proof: Suppose that sched(z)|B 4 sched(y). Since x and y are the limits of finitely cor- 
responding prefixes z; and y,, respectively, there must be an ¢ such that sched(z;)|B 4 
sched(y;). However, since y; finitely corresponds to z; under h, this is impossible. Thus, 
sched(xr)|B = sched(y). Oj 


Having established a correspondence between the executions of A and B, we show 
with the following result how this correspondence can be used to show that A satisfies B. 
We say that one equivalence relation is a contained in a second if every class of the first 
is contained in a class of the second. 


Lemma 30: Let A and B be automata such that part(B) is contained in part(A). 
Let h be a possibilities mapping from A to B. Suppose the following condition holds 
for all reachable states a of A and for all classes C and D of part(A) and part(B), 
respectively, such that C D D: If an action of D is enabled from a reachable state. 
of h(a), then an action of D is enabled from a and no action of C — D is enabled 
from a. 


Proof: Since h is a possibilities mapping from A to B, both automata have the same 
external action signature. We need only show that fbeh(A) C fbeh(B). Let z be a fair 
execution of A, and let y be an execution of B corresponding to z under h. We claim 
that y is a fair execution of B. Since sched(z)|B = sched(y) and ext(A) = ezt(B), we 
will have that sched(z)|ezt(A) = sched(y)|ezt(B), and hence that fbeh(A) C fbeh(B). 
For each + > 0, let 2; be the prefix ag7,a, ... a; of z, and let y; be the prefix of y finitely 
corresponding to 2; under h. 


Suppose y is finite. Suppose there is a class D of B such that an action of D is 
enabled from the final state of y. Since y is finite, y = y; for some t. Since an action 
of D is enabled in B from a reachable state in h(a;) for all 7 > + (namely, the final state 
of y), for all y > ¢ an action from D is enabled in A from a,;, and no action from C — D 
is enabled in A from a;. If z is finite, then an action of C is enabled from the final state 
of z. If z is infinite, then from every state a; (j > 1) an action of C is enabled and yet 
no action of C is performed (or it would appear in y). In either case, this contradicts 
our initial assumption that z is a fair execution, so y must be a fair execution of B. 


Conversely, suppose y is infinite. Suppose there is a class D such that an action 
from D is enabled from all but finitely many states appearing in y. It follows that for 
all but finitely many i, an action of D is enabled from a reachable state of h(a;) in B. 
Therefore, for all but finitely many 1, there is an action of D enabled from a; in A, and 
no action from C — D enabled from a;. Since z is a fair execution of A, there must be 
infinitely many actions from D appearing in z, and hence in y. Therefore, y must be 
a fair execution of B. O 


45 


We remark that the requirement that part(B) be contained in part(A) is not un- 
reasonable when B models an algorithm at a higher level of abstraction than A. The 
restriction implies that the actions of B are a subset of the actions of A. Since A and B 
have the same external action signature (A is a possibilities mapping from A to B), 
this implies that some low-level internal actions of A may not be internal actions of B. 
Even when this requirement is not met, however, the correspondence between states 
established by a possibilities mapping is still a useful correspondence when reasoning 
about the behavior of the automaton. For example, in Section 2.3.2 we will see how 
this correspondence can be used to verify that one execution module (of an automaton) 
satisfies a second. 


Our final result concerning possibilities mappings shows that possibilities mappings 
have a very nice local behavior: Given two automata A = [],; A; and B = []; B; together 
with a possibilities mapping from A; to B, for every 1, these possibilities mappings 
induce a possibilities mapping from A to B. 


Lemma 31: Suppose for all s € J that A; is a possibilities mapping from A; to B;, and: 
that acts(A;) D acts(B;). Let A = J]; A; and B = J]; B;. If A is the mapping from 
states(A) to the power set of states(B) defined by h(a) = {6 : 6|B; € h;(a|A;)}, then h 
is a possibilities mapping from A to B. 


Proof: As a result of Corollary 8, the external action signature of a composition is the 
composition of the external action signatures of its components. Since the A; and B; 
have the same external action signatures, A and B must also have the same external 
action signature. Thus, we need only check that conditions 1 and 2 of a possibilities 
mapping hold. For the first condition, for every a; € start(A,) there is a &; € states(B;) 
such that 6; € h,(a;). Thus, for every a € start(A) there is a 6 € start(B) such that 
b € h(a). For the second condition, suppose that a is a reachable state of A, (a,7,a’) 
is a step of A, and 6 € h(a) is a reachable state of B. Let a; = a|A;, a, = a'|A;, and 
6; = 6|B; for every 1 € I. Notice that, since a and 6 are reachable states of A and B, 
a; and 6; must be reachable states of A; and B;. 


Suppose that x € acts(B). We must construct a step (6,7, 0’) of B with & € h(a’). 
Suppose 7 € acts(B;). Then  € acts(A;), so (a;,%,a,) must be a step of A,. Since h; 
is a possibilities mapping from A; to B,, there is a step (6;, 7,0) of B; with 6; € A;(a}). 
Suppose  ¢ acts(B,). If x € acts(A;), then (a;,7,a{) is a step of A;, and 6; € h,(a{) 
by definition of h;. If x ¢ acts(A;), then a; = aj, and so 6; € h,(a;) = h,(a{). In either 
case, let b; = 6;. It follows that (b;,7,6}) is a step of B; if r € acts(B,), and that 6; = oj 
if » ¢ acts(B,). If 6 is the state of B such that b; = |B; for all 1, then (6,7,’) isa 
step of B. Furthermore, &' € h(a’) as desired. 


Suppose that x ¢ acts(B). Then x ¢ acts(B;) for all s. As above, 6; € h,(a;) for 
all i, and so 6 € h(a’) as desired. Thus, A is a possibilities mapping from Ato B. O 
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2.3.2 Execution Module Satisfaction 


As previously mentioned, when constructing the correctness proof of an algorithm, we 
first construct automata A,,...,A, describing the algorithm at several levels of ab- 
straction. If the algorithm is required to satisfy certain liveness conditions, we also 
construct execution modules E; of A; describing these liveness conditions. The remain- 
der of the correctness proof consists of proving that each E; satisfies E;.;. We now 
show how possibilities mappings can be used to prove that certain execution modules 
satisfy other execution modules. 


We remark that one correctness condition common to many system specifications 
is a condition of the form “if condition P holds, then eventually condition Q holds.” 
Lamport denotes this temporal logic statement 0(/P > OQ) by P ~ Q in [Lam77], 
read “P leads to Q.” Given an automaton A, a set of states S, and a set of actions T, a 
simple correctness condition common to specifications in our model (see Chapter 3, for 
instance) is the condition “if the current state of A is contained in S, then eventually 
an action of T will be performed.” With Lamport’s notation in mind, we denote this 
condition by S «+ T.! Given two execution modules E and F satisfying a collection of. 
such conditions, we now show how a possibilities mapping can be used to show that E 
satisfies F. We begin with a result relating individual executions. 


Lemma 32: Let A be a possibilities mapping from A to B. Let x be an execution 
of A, and let y be an execution of B corresponding to z under h. 


1. If y satisfies U ~ V, and if h(S) C U and T D V, then z satisfies S — T. 
2. If z satisfies S — T, and if S > h~\(U) and T C V, then y satisfies UV. 


Proof: Let x = apm, a,..., and let y = b9¢,5,.... For each 1 € J, let x; = aoma)...4;, 
and let y; be the prefix of y finitely corresponding to z; under h. 


Suppose y satisfies U — V, and let us show that z satisfies S —» T. It is enough 
to show that if a, € S, then x, € T for some £ > k. Since y, finitely corresponds to z, 
under h, we have yz = 61416,...6, with b, € A(a,) for some m. Since a, € S and 
h(S) C U, we have b, € U. Since y satisfies U + V, we have y, € V for some n > m. 
Since V C T, for some é > k we have sched(x,)|B = sched(y,) where sched(x,)|B and 
sched(y,) both end with ~,. Therefore, for some 4 > k we have ™ = Ym € T, as 
desired. 


Conversely, suppose z satisfies S —+ T, and let us show that U < V is satisfied by y. 
It is enough to show that if b, € U, then wy, € V for some ¢ > k. Since ym = bo%1... dy 


1The statement S — T is essentially a statement in temporal logic, as is O(/P > OQ). The fact that 
executions are sequences of states and actions, instead of simply infinite sequences of states, means the 
standard model for temporal logic must be slightly modified if the condition S — T is to be expressed 
in temporal logic. 
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finitely corresponds to 2, = ao71...@m for some m, we have by € h(am). Since 6, € U 
and h-!(U) C S, we have am € S. Since z satisfies S + T, for some n > m we have 
™, © T. Since sched(z,)|B = sched(y,) and T C V C aets(B), we see that the final 
action of yy, is mn. If yn = bo... ebz, then ye = 7, © V for some £ > &k as desired. OO 


With this result, we are now able to give the following sufficient condition for the 
satisfaction of one execution module by another. 


Lemma 33: Let h be a possibilities mapping from A to B. Let E be the execution 
module of A with the executions of A satisfying the conditions S; <> T; for every 
t © I, and let F be the execution module of B with the executions of B satisfying the 
conditions U; <> V; for every : € I. If for every i € I we have that 5; D> h~!(U;,) and 
T; C V;, then £ satisfies F. 


Proof: Since h is a possibilities mapping from A to B, these automata (and hence 
the execution modules E and F) have the same external action signature. Let z be an 
execution of E, and let y be an execution of B corresponding to z under h. Since z 
satisfies S; + T; for every 1, Lemma 32 implies that y satisfies U; — V; for every +. It 
follows that y is an execution of F. Therefore, fbeh(E) C fbeh(F), and E satisfies F. 

Oj 


We conclude with a simple result relating conditions of the form S <> T satisfied 
by executions of a composition of automata to conditions of the form S' — T" satisfied 
by executions of an individual component. 


Lemma 34: Let A = Hidey([]; A;). Let S C states(A), and let S; = {s|A; : 8 € S}. 
If z is an execution of A, then z satisfies the S — T iff z|A; satisfies S; — T. 
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Chapter 3 


An Example 


As an example of the hierarchical organization of correctness proofs proposed in the 
preceding chapter, in this chapter we prove the correctness of Schoénhage’s distributed. 
resource allocation algorithm described in the introduction. The problem is to design 
an arbiter allocating a resource among a collection of users that guarantees the mutual 
exclusion condition that at most one user is using the resource at any given time; 
and the no lockout condition that if users holding the resource eventually return the 
resource, then the arbiter will eventually satisfy every requesting user. The distributed 
system in which this arbiter is to be used is completely asynchronous: processor speeds 
may be independent; messages may take an arbitrary, finite amount of time to be 
delivered; and messages may be delivered in any order. 


The arbiter itself is described in parallel with the proof of its correctness. We begin 
with a high-level model serving as a simple specification of the problem the arbiter is 
to solve. We then give a graph-theoretic description of the algorithm’s global behavior. 
Finally, the arbiter is distributed and described in terms of a low-level protocol to be 
followed by the processors comprising the arbiter. We show that this low-level model 
solves the high-level problem specification, and hence that the given protocol is a correct 
solution to the arbiter’s problem specification. 


3.1 The Automaton A, 


Our high-level model of the arbiter, the automaton A), is a very simple specification 
of the arbiter’s correctness conditions. We refer to the arbiter itself as a, and to the 
users of the arbiter as u,...,tn.! 


1In general, we will denote entities associated with the arbiter by the letter a, and entities associated 


with the users by letter u. Letters near the end of the alphabet such as v and w will be used to denote 
entities associated with either the arbiter or the users. 
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Input Actions: 
request(u) 
effects: 
requesters — requestera U {u} 
return(u) 
effects: 
if holder = u then 
holder —a 


Output Actions: 
grant(u) 

preconditions: 
tu € requestere 
holder =a 

effects: 
requesters — requesters — {u} 
holder —u 


Figure 3.1: The actions of A). 


3.1.1 The States of A, 


A state of A; consists of a set requesters C {u1,..., tn} of requesting processes, together 
with a value holder € {u1,..., un, @} indicating the entity currently holding the resource 
(either a user or the arbiter itself). The start state of A; is the state in which the set 
requesters of requesting users is empty, and the initial holder is the arbiter a itself. We 
note that all states of A, are reachable, as will become clear when the actions of A; 
have been introduced. 


3.1.2 The Actions of A; 


The actions of A; are given in Figure 3.1. We specify the transition relation of an 
automaton by giving for each action a list of preconditions and effects. An action is 
enabled from any state s satisfying the action’s preconditions, and the action takes s 
to the state ¢ if t can be obtained by modifying s as indicated by the action’s effects. 
Since input actions are enabled from every state, we omit the preconditions of input 
actions. 


The input actions of A; are of the form request (u) and return(u), where u is a user. 
The action request(u) simply places the user u in the set requesters of requesting users. 
Since automata are input-enabled, a user is able to request the resource at any time, 
even when it is currently holding the resource. The effect of a user’s requesting the 
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resource while holding the resource is that the request is recorded for later use (later 
servicing of the user). The action return(u) returns the resource to the arbiter by 
making the arbiter the new holder of the resource. Notice that if a (faulty) user tries 
to return the resource when it does not actually hold it, the arbiter simply ignores the 
“return.” The automaton A, has no internal actions. The output actions of A; are of 
the form grant(u), where u is again a user. The arbiter grants the resource to u with 
the action grant(u), which removes u from the set of requesting users and makes u 
the new holder of the resource. Notice that the arbiter grants the resource only when 
the arbiter actually holds the resource. Consequently, at most one user is using the 
resource at any time. 


3.1.3 The Execution Module E£, 


While the executions of A satisfy the mutual exclusion condition that at most one user 
is using the resource at any given time, we must still ensure the no lockout condition 
is satisfied by the arbiter: If users using the resource eventually return the resource to. 
the arbiter, then the arbiter eventually satisfies every request for the resource. Let u 
be a user node, and let us define the following sets of states and actions.” 


RtnResi(u) = {8 € states(A;) : holder = u in s} 


RinResi(u) = {return(u)} 
GrResi(u) = {8 € states(A;) : u € requesters in s} 
GrRest(u) = {grant(u)} 


The condition 
RinRes, = /\ RinRes{(u) > RtnRest(u) 


says that any user holding the resource will eventually return the resource to the arbiter. 
The condition 


GrRes; = /\ GrResi(u) + GrRes{(u) 


says that any user requesting the resource will eventually be granted the resource. The 
correctness condition 
C,; = RtnRes, > GrRea, 


2 We will be defining several correctness conditions for each of the models we study. We will subscript 
these conditions to indicate the level of abstraction with which they are associated. Furthermore, the 
sets of states and actions used to construct these conditions will be superscripted with the letters s or a, 
respectively. 
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Figure 3.2: One state of the arbiter modeled by A3. 


says that if users holding the resource always return the resource, then users requesting 
the resource will always be granted the resource. This is precisely the no lockout 
condition we require the arbiter to satisfy. We denote by FE, the execution module 
of A; with the executions of A; satisfying the condition C,. The execution module E, 
serves as the specification of the arbiter. 


3.2 The Automaton A, 


Our next model reveals the distributed structure of the arbiter, but still at a high level 
of abstraction, a level at which one might describe the algorithm at the blackboard. In 
this model, illustrated in Figure 3.2, the arbiter and its environment are modeled by 
a connected, acyclic graph G. The leaves of G are user nodes representing the users, 
labeled u;,...,tU,. The arbiter itself consists of the remaining arbiter nodes, labeled 
@1,...,@m. The (directed) edge of G from the node v to w is denoted by (v,w). An 
edge (v,w) is said to point toward a node z if (v,w) is an edge in the path from v to z. 
Arrows are placed on edges of the graph to indicate either a request for the resource 
or the granting of the resource. In general, the resource is considered to be held by a 
node at the head of a grant arrow. Such a node is called a root of the graph. A user u 
requests the resource by placing a request arrow on the edge (u,a) from itself to the 
adjacent arbiter node a. The arbiter grants the resource to u by removing this arrow 
and placing a grant arrow on (a,u). The user then returns the resource by moving the 
grant arrow from the edge (a,u) to the edge (u,a). The arbiter itself, however, is an 
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acyclic graph of arbiter nodes. When the head of a request arrow is placed at an arbiter 
node a, the arbiter node’s response depends on whether it is holding the resource. If 
the arbiter node a holds the resource, then it must be at the head of a grant arrow, 
and so there must be a grant arrow on some edge (v,a). The arbiter selects the first 
node w in some fixed ordering of its adjacent nodes having a request arrow on (w,a). 
The arbiter then grants the resource to this node by removing the request arrow and 
moving the grant arrow to the edge (a,w). In this case we say that the resource has 
been forwarded by a to w. If the arbiter node a does not hold the resource, then the 
arbiter forwards the request in the direction of a node holding the resource by placing a 
request on the edge pointing toward a root. The work in this section holds for arbitrary 
connected, acyclic graphs. When we consider the model As in the following section, 
however, we will restrict our attention to graphs with a particular structure. 


3.2.1 The States of A, 


In order to refer conveniently to the arrows on an edge of the graph, we associate with 
each edge (v,w) an arrow set, arrows(v,w), containing all of the arrows on the edge 
(v,w). A state of A; therefore consists of one arrow set, arrows(v,w), for every edge 
(v,w) of the graph G. The start states of A; are taken from the set of states in which a 
single arrow set arrows(v,a) contains only a grant arrow, and all other arrow sets are 
empty, where a is an arbiter node of the graph G. In such a state, the arbiter holds 
the resource and no requests for the resource are pending. We will soon restrict our 
attention to a particular set of such start states in the next section, but the work of 
this section is independent of the particular set chosen. We note that some states of A: 
are unreachable. For technical convenience, we remove these states from A; so that all 
states of Az are reachable. 


3.2.2 The Actions of A, 


Fix for each node of G an (arbitrary) ordering of its adjacent nodes. Let (v,w) denote 
the set of nodes properly between the nodes v and w in this ordering, and let (v, w| 
denote the set nodes properly between v and w together with the node w. The actions 
of A, are given in Figure 3.3. The input actions are of the form request(u,a) and 
grant(u,a), and the output actions are of the form grant(a,u), where u is a user node 
and a is an adjacent arbiter node. The internal actions are of the form request (a, u) 
where u is a user node and a is an adjacent arbiter node; and of the form request (a, a’) 
and grant(a,a’) where a and a’ are adjacent arbiter nodes. As in the previous model, 
users may request or grant the ticket at any time, but grants by users not actually 
holding the ticket are effectively ignored. Note we have added internal actions with 
which the arbiter may request that the user return the resource. The arbiter had no 
such ability in the previous model. These actions have been added for the sake of 
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Input Actions: 
request(u, a) 
effects: 
arrows(u,a) — arrows(u, a) U {request} 
grant(u, a) 
effects: 
if grant € arrows(a, u) then 
arrows(a, u)  arrows(a,u) — {request} 
arrows(a, u) + arrows(a,u) — {grant} 
arrows(u, a) — arrowa(u, a) U {grant} 


Internal and Output Actions: 
request(a, v) 
preconditions: 
request € arrows(w,a) for some w 
(a, v) points toward a root 
request ¢ arrows(a, v) 
effects: 
arrows(a,v) — arrows(a,v) U {request} 
grant(a, v) 
preconditions: 
request € arrows(v, a) 
grant © arrows(w, a) for some w 
request ¢ arrows(y,a) for y € (w,v) 
effects: 
arrows(v,a) — arrows(v, a) — {request} 
arrows(w,a) + arrowe(w,a) — {grant} 
arrowe(a,v) — arrows(a,v) U {grant} 


Figure 3.3: The actions of A3. 
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symmetry. Having been added as internal actions, they have no effect on the arbiter’s 
interface with its users. 


The next few results state certain invariants that hold during executions of A;. The 
first guarantees that every state contains at most one root, and hence that at most one 
user is using the resource at any time. 


Lemma $5: If s is a state of A;, there is exactly one root in s. 


Proof: In every start states of A;, precisely one arrow set contains a grant arrow. 
Furthermore, every action that adds a grant arrow to an arrow set also removes a 
grant arrow from an arrow set. The result follows by a simple inductive argument, 
since all states of A, are reachable. O 


The second invariant states that every request arrow placed on the graph by the 
arbiter points toward the root of the graph. In other words, the arbiter correctly 
forwards requests in the direction of the resource. 


Lemma 36: Let s be a state of A;, and let a be an arbiter node of G. If arrows (a, v) 
contains a request arrow, then (a,v) points toward the root of G. 


Proof: No arrow set of any start state contains a request arrow, so the start states of A; 
certainly satisfy the hypothesis. Suppose s is a state of A; satisfying the hypothesis, 
and suppose that s — ¢ is a step of A;. We claim that t satisfies the hypothesis as well. 
Suppose a is of the form request(z,y). Notice that x does not modify the position of 
the grant arrow, and that 7 adds a request arrow to arrows(a,v) only if (a,v) points 
toward the root in s, and hence in t. It follows that ¢ must satisfy the hypothesis. 
Suppose x = grant(v,a). In this case, removes any request arrow from arrows(a,v), 
and so t must satisfy the hypothesis. Finally, suppose * = grant(z,y) # grant(v,a). 
Since x does not add or remove a request arrow from arrows (a,v), if the set arrows (a, v) 
contains a request arrow in t, the same is true in s. The fact that x is enabled from s 
implies that z is the root in s. The hypothesis implies that the edge (a,v) must point 
toward the root z in s. Since x forwards the resource from z to y (and since y # a) the 
edge (a,v) must point toward the root y in t. Therefore, t must satisfy the hypothesis. 
The lemma now follows by a simple inductive argument, since all states of A: are 
reachable. | 


3.2.3 The Execution Module £, 
To ensure that the arbiter satisfies all user requests, it is obviously important that the 


internal arbiter nodes forward all requests in the direction of the root, and that arbiter 
nodes holding the resource eventually grant the resource to adjacent requesting nodes. 
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Let a be an arbiter node adjacent to nodes v and w, and let us define the following sets 
of states and actions. 


FwdReq3(a,v) = {s € states(A2) : request € arrows(w,a) for some w, 
(a,v) points toward the root, and 
request ¢ arrows(a,v) in s} 
FwdReq3(a,v) = {grant(v,a), request (a,v)} 


FwdGr3(a,v,w) = {8 € states(A;) : request € arrows(v,a) and 
grant € arrows(w,a) in s} 


FwdGr}(a, v, w) {grant(a,y) : y € (w,v]} 


The first arbiter correctness condition 


FwdReq, = /\ FwdReq3(a,v) — FwdReq3(a, v), 
illustrated at the top of Figure 3.4, states that if an arbiter node a is at the head of 
a request arrow and has not forwarded the request in the direction of the root, then 
either a becomes the root (possibly because v is a user node, and v has placed a grant 
arrow on (v,a)), or a eventually forwards the request in the direction of the root. The 
second arbiter correctness condition 


FwdGr, = /\ FwdGr}(a,v,w) — FwdGr}(a,v,w), 


illustrated at the bottom of Figure 3.4, states that if an arbiter node a is a root at 
the head of a request arrow, then it eventually forwards the resource to an adjacent 
requesting node. The correctness condition 


C; = FwdReq, \ FwdGrz 


ensures that arbiter nodes always forward requests in the direction of the root; and 
that arbiter nodes holding the resource always grant it to adjacent requesting nodes. 
We let E; be the execution module of A; with the executions of A; satisfying the 
condition C3. 


While Lemma 35 states that at most one user is using the resource at any given 
time, and while condition C; ensures that arbiter nodes holding the resource always 
grant the resource to requesting nodes, we have not yet shown that the arbiter always 
satisfies user requests. As before, this requires cooperation on the part of the users. 
Let u be a user node adjacent to the arbiter node a, and let us define the following sets 
of states and actions. 


RinRes;(u) = {s € states(A2) : grant € arrows(a,u) in s} 
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Figure 3.4: Arbiter correctness conditions. 
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RinRes;}(u) = {grant(u,a)} 


GrRes3(u) = {8 € states(A2) : request € arrows(u,a) in s} 
GrRes}(u) {grant (a, u)} 


The condition 
RtnRes, = /\ RtnRes3(u) > RtnRes}(u) 
w 


says user nodes holding the resource always return the resource, and the condition 


GrRes, = /\ GrRes;(u) — GrRes3(u) 


says the arbiter eventually satisfies requesting users. The condition RtnRes, > GrRes, 
says that if users return the resource, then the arbiter satisfies all requests. We now 
show that every execution of E; satisfies the condition RinRes; > GrRes,. First, 
however, we prove the following result, the inductive statement in the argument that 
E;, satisfies the condition RinRes, > GrRes. 


Lemma 37: Let s be a state of A; having a request arrow in arrows(v,w). Let z be 
an execution fragment of A; from s satisfying the condition C; A RtnRes,. Then the 
action grant(w,v) must appear in z. 


Proof: If the graph G is viewed as a tree rooted at v, then w can be viewed as the 
root of a subtree of v. We proceed by induction on the height h of the subtree of v 
rooted at w. 


Suppose h = 0. In this case, w must be a leaf of G, and therefore w must be a 
user node and v an arbiter node. Since v is an arbiter node and arrows(v,w) contains 
a request arrow, Lemma 36 implies the edge (v,w) points toward the root. Therefore, 
arrows (v,w) must contain a grant arrow. Since z satisfies RtnRes;, the user w must 
eventually return the resource to the arbiter, and hence grant(w,v) must appear in z. 


Suppose h > O and the inductive hypothesis holds for h — 1. We first show that z 
can be written as az’ where z’ is an execution fragment satisfying C;A RtnRes, in whose 
initial state request € arrows(v,w) and w is the root (that is, grant € arrows(w’, w) for 
some node w’). We consider two cases. First, suppose (v,w) does not point toward the 
root in s. Since arrows(v,w) contains a request arrow, Lemma 36 implies that v must 
be a user node. Since user nodes are leaves, and since (v,w) does not point toward 
the root, the root must be at v; that is, arrows(w,v) must contain a grant arrow. 
Since z satisfies RtnRes,, the user v must eventually return the resource to the arbiter, 
so grant(v,w) must appear in x. Therefore, z = fgrant(v,w)z’ as desired. Now, 
suppose (v,w) does point toward the root. If w itself is the root, then setting z’ = z 
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we are done, so suppose w is not the root. If for some node w’ the set arrows (w, w’) 
contains a request arrow, then since the height of the subtree of w rooted at w’ must be 
less than h, the inductive hypothesis for h — 1 implies that grant(w',w) appears in z. 
Therefore, z = Bgrant(w',w)z’ as desired. On the other hand, suppose no arrow set 
arrows (w,w') contains a request arrow. Note that the fact that h > 0 implies that w 
is not a leaf, and hence that w is an arbiter node. Since z satisfies C2, we see that for 
some node w’ either grant(w’, w) or request (w, w') appears in x. If grant(w',w) appears 
in z, then z = Ggrant(w',w)z' as desired. If request(w, w') appears in z, then a request 
arrow is placed in arrows(w,w’'), and again the inductive hypothesis for h — 1 implies 
that z = Bgrant(w',w)z' as above. 


We now show that if z’ is an execution fragment satisfying C3 A RtnRes, in whose 
initial state request € arrows(v,w) and grant € arrows(w',w) for some node w’, then 
grant(w,v) appears in z’. From this it will follow that grant(w,v) appears in z as 
well. We proceed by induction on d, the distance from w’ to v in the ordering of 
the nodes adjacent to w in G. Suppose d = 1. Since request € arrows(v,w) and 
grant € arrows (w',w), condition C2 implies that grant(w,y) must appear in z’ for some. 
y € (w’,v] = {v}. Thus, grant(w,v) must appear in z’. Suppose d > 1 and the inductive 
hypothesis holds for d — 1. Suppose the inductive hypothesis does not hold for 2’: 
Suppose that grant(w,v) does not appear in 2’, and hence that request € arrows(v, w) 
in every state appearing in z’. As in the case of d = 1, the action grant(w,y) must 
appear in z’ for some y € (w’,v]. If y = v then we are done, so suppose y # v. If 
arrows (w,y) contains a request, then the inductive hypothesis for h — 1 implies that 
grant (w,y) appears in z’, and the inductive hypothesis for d—1 implies that grant(w, v) 
must also appear in z’. On the other hand, suppose arrows(w,y) does not contain a 
request arrow. Condition C, implies that either grant(y,w) or request(w,y) appears 
in 2’. If grant(y, w) appears in z’, then a grant arrow is placed in arrows(y,w), and the 
inductive hypothesis for d — 1 implies that grant(w,v) appears in z’. If request (w,y) 
appears in 2’, then a request arrow is placed in arrows(w,y), and grant(w,v) must 
appear in 2’ as we have seen above. 


An immediate corollary of Lemma 37 is the following. 


Corollary 38: Every execution of EF; satisfies the condition RtnRes; > GrRes3. 


3.2.4 The Execution Module EF; 


For the sake of exposition, we have given the actions of A; names suitable to its level 
of abstraction, rather than using names from A. It is therefore necessary to rename 
these actions before showing that E; solves E,. The action mapping f; from A; to A; 
is defined to map 
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request(u,a) to request(u), 
grant(u,a) to return(u), 
grant(a,u) to grant(u), 


and all remaining (internal) actions to themselves. We will denote by A the automaton 
fi(Az), and in general we will denote by affixing a prime to its name the entity obtained 
by renaming its actions according to /,. 


3.2.5 The Satisfaction of E, by Ej 


We begin the proof that E} satisfies E, by exhibiting a possibilities mapping from Aj 
to A;. The mapping h, maps the state s of A} to the state t of A; such that 


u€ requesters int iff request € arrows(u,a) in s 
holder =uint iff grant € arrows(a,u) in s 
holder =aint iff grant ¢ arrows(a,u) for every user u in s 


These conditions ensure that a user is a requesting user in ¢ iff it is in s, and that a 
user is holding the resource in t iff it is in s. Since all states of Aj are reachable, and 
since in all reachable states of A there is exactly one root, this mapping takes each 
state of Aj to a singleton set of states of Aj. 


Lemma 39: The mapping /, is a possibilities mapping from A} to Aj. 


Proof: The automata Aj and A, clearly have the same external action signature. If s 
is a start state of A2, then a single arrow set arrows (v,a) contains a grant arrow and all 
other arrow sets are empty. In particular, no arrow set arrows(u,a) contains a request 
arrow, and no arrow set arrows(a,u) contains a grant arrow. Therefore, in every state 
of h(s) the set requesters of requesting users is empty, and holder = a. Since this is 
the start state of A, we see that if s is a start state of A}, then a start state of A; is 
contained in h,(s). 


Consider the action * = request (u) of Aj, originally the action request (u,a) of Az. 
Suppose s and ¢ are reachable states of Aj and Aj, respectively, such that ¢ € h;(s). 
The action 7 is an input action of both automata, and hence is enabled from both s 
and t. Suppose s — s' and t - t'. Since x adds a request arrow to arrows(u,a) in s’, 
and adds u to requesters of requesting users in t', we see that t’ € h,(s’). 


Consider the action = return(u) of Aj, originally the action return(u,a) of A2. 
Suppose s and ¢ are reachable states of Aj, and Aj, respectively, such that ¢ € hj(s). 
Again, x is an input action of both automata, and hence is enabled from both s and t. 
Suppose s -> s' and t — t’. The definition of h, implies that grant € arrows(a,u) in s 
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iff holder = u in t. If both conditions are false, then w has no effect on either s or t, 
so ¢t € h;(s) implies t’ € h,(s'). Suppose both conditions are true. Notice that u is the 
unique root in s. The action 7 moves the grant arrow from arrows (a, u) to arrows (u, a) 
in s', and x sets holder to a in t'. Thus, t' € h,(s'). 


Consider the action * = grant(u) of Aj, originally the action grant(a,u) of A3. Sup- 
pose s and ¢ are reachable states of A} and Aj, respectively, such that t € f(s). If x is 
enabled from s, then request € arrows(u,a) and grant € arrows(w,a) for some node w. 
Since request € arrows(u,a) in s, the set requesters of requesting users contains u in t. 
Since a is the unique root in s, holder = a in t. Thus, 7 is enabled from t. Suppose 
s + s' and t + t'. The action x removes the request arrow from arrows(u,a) and 
moves the grant arrow to arrows(a,u) in s’, and 7 removes u from the set requesters 
of requesting users and sets holder to u in t'. Therefore, t’ € hi(s'). 

Finally, the remaining actions request(a,u), request(a,a’), and grant(a,a') of Aj 
are not actions of A,. These actions do not affect request arrows in the arrow sets 
arrows (u,a) or grant arrows in the arrow sets arrows(a,u). Therefore, suppose s and t 
are reachable states of A, and A; such that t € A,(s). If s — 8’ is a step of A}, then. 
t € hi(s’). It follows that h; is indeed a possibilities mapping from Aj to Aj. i 


We can now show that E} satisfies EF. 
Lemma 40: E; satisfies Fj. 


Proof: Let z be an execution of E}, and let y be an execution of A; corresponding 
to y under hy. First, we claim that (i) if y satisfies RtnRes{(u) > RtnRes{(u), then z 
satisfies RtnRes,(u) + RtnRes}(u)'. Suppose s is a state of RinRes3(u). Since grant € 
arrows(a,u) in 8, we see that holder = u in every state of hi(s), and hence that 
h,(RinRes;(u)) C RtnRes{(u). Since, in addition, RtnRes}(u) C RtnRes}(u)', the claim 
follows by Lemma 32. Second, we claim that (ii) if z satisfies GrRes}(u) + GrRes?(u)', 
then y satisfies GrRes{(u) —+ GrRes{(u). Suppose t € A; (s) is a state of GrRes{(u). 
Since u € requesters in t, we see that request € arrows(u,a) in s, and hence that 
hy'(GrRest(u)) C GrRes}(u). Since, in addition, GrRes$(u)' C GrRes?(u), the claim 
follows by Lemma 32. From observations (i) and (ii) it follows that if y satisfies RtnRes,, 
then z satisfies RtnRes,; and that if z satisfies GrRes,, then y satisfies GrRes,. Since z 
satisfies RtnRes, > GrRes, it follows that y satisfies RtnRes; > GrRes,, and hence 
that y is an execution of E,. Since sched(z)|Ai = sched(y), and since Ej and EF, have 
the same external action signature, it follows that fbeh(E}) C fbeh(E,), and hence that 
E; will satisfy E;. QO 


3.3 The Automaton A; 


In the description of the arbiter given by the previous model, the arbiter nodes are 
intended to represent processes in a distributed network implementing the arbiter. 
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Previous models have given global descriptions of the arbiter’s behavior. In this model 
we actually distribute the arbiter by modeling each process as a separate automaton. 
These automata describe the low-level protocol followed by each process in the arbiter’s 
implementation. Notice that while previous models have acknowledged the asynchrony 
of processor step times, they have essentially ignored the asynchrony of the network’s 
message system by assuming instantaneous message delivery. We now introduce this 
asynchrony into the model, modeling the message delivery system as an independent 
automaton. By composing the automata modeling arbiter processes with the automa- 
ton modeling the message delivery system, we obtain a global model of the arbiter. 


In order to model asynchronous message delivery, it is convenient to add to the 
graph G an extra arbiter node 6,4 (or 6:4) between every pair of adjacent arbiter 
nodes a and a’. The node 6,4’ acts as a message buffer between a and a’: The node a 
sends a message to a’ by placing an arrow on the edge (a, 6,4’), and the message system 
delivers the message to a’ by placing an arrow on the edge (b,,4',a'). Since they function 
as message buffers, we will hereafter refer to the nodes 6, ,: as buffer nodes. We denote 
by G the graph obtained from G by the addition of such buffer nodes. Two nodes. 
(processes) are said to be adjacent in G if they are separated by at most a buffer node; 
that is, if they are user or arbiter nodes adjacent in the graph G. Since the results of 
the previous section hold for arbitrary connected, acyclic graphs, and since G is such a 
graph, these results hold for the graph G. We therefore fix G as the graph underlying 
the model A;. Furthermore, we fix as the set of start states of A; those start states 
in which no buffer node is a root. In such states, the arbiter holds the resource, and 
no undelivered messages are pending. We note that with the added structure of G, we 
can prove the following result about buffer nodes during executions of A3. 


Lemma 41: Let a and a’ be adjacent arbiter nodes, and let s be a state of A2. If 
request € arrows (baa',a') or grant € arrows(a’,b,4/), then request € arrows (a, baa’). 


Proof: The sets arrows (b.4:,a') and arrows(a’,b,4:) do not contain request or grant 
arrows, respectively, in any start state of A;, and hence every start state satisfies 
the hypothesis. Suppose s is a reachable state of A; satisfying the hypothesis, and 
suppose s —> t is a step of As. We claim that ¢ satisfies the hypothesis was well. If 
x = request (z,y), then 7 places a request arrow in arrows(z,y). The only case we need 
consider is the case of (z,y) = (ba4/,a’). In this case, w is enabled only if (ba,.',@’) 
points toward the root, and there is a request in arrows(v,bo,') for some v. If vy =a’, 
then Lemma 36 implies that the edge (a’,6,4') also points toward the root. Since 
Lemma 35 states that there is only one root, this is clearly impossible. Therefore, 
we must have v = a, and hence that ¢ satisfies the hypothesis. If = grant(z,y), 
then a places a grant arrow in arrows(z,y). The only case we need consider is the 
case of (z,y) = (a',bga:). In this case, 7 is enabled only if there is a request arrow in 
arrows (baa',a’) in s. By hypothesis, there must be a request arrow in arrows (a, ba,.') 
in s, and hence in t. Therefore, ¢ must satisfy the hypothesis. The lemma follows by a 
simple inductive argument. O 
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Note that we do not model any message asynchrony between users and the arbiter: User 
nodes are to be interpreted as ports to the arbiter through which the users communicate 
with the arbiter, and not the user processes themselves. If the arbiter is to be used in 
a larger system, then the responsibility of modeling the message delivery between the 
arbiter and the rest of the system falls on the model of the larger system’s message 
delivery. 


The previous models have given some indication of the behavior required of arbiter 
processes. In the first place, arbiter processes must always forward a request for the 
resource in the direction of the resource. Since the network is acyclic, the process is 
able to determine the direction of the resource by remembering the direction in which it 
last forwarded the resource. Furthermore, arbiter processes holding the resource must 
forward the resource to a requesting process. In particular, if arbiter process a receives 
the resource from process v, then a must grant the resource to the first requesting 
process after v in a fixed ordering of its neighbors. Therefore, the state of an arbiter 
process is determined by a set of processes from which it has received a request, the 
link over which the resource was last sent, whether or not the process is holding the 
resource, and whether or not a request has been forwarded in the direction of the 
resource. For each arbiter process a (each arbiter node of the graph G), we construct 
an automaton A, modeling the process a. 


The behavior required of the message system is very simple. The system must be 
able to accept messages for delivery, and ensure that every message sent is eventually 
delivered. The state of the message system is simply a collection of undelivered mes- 
sages, together with their destinations. We construct an automaton M to model the 
asynchronous message communication system. 


3.3.1 The States of A, and M 


As mentioned above, a state of A, is determined by a set requesting of requesting 
processes adjacent to a, a variable lastforward indicating the adjacent process to which a 
last forwarded the resource, a binary flag holding indicating whether or not a is holding 
the resource, and a binary flag requested indicated whether or not a has requested the 
resource since last holding the resource. To define the start state of A,, we designate 
one of the arbiter processes and the initsal holder of the resource. The start state of A, 
is a state in which the set requesting of requesting processes is empty; the variable 
lastforward is set to the process adjacent to a on the path from a to the process 
currently holding the resource, or to any adjacent process if a is the initial holder; the 
flag holding is set depending on whether a is the initial holder; and the flag requested 
is set to false. Notice that there are several possible initial states for the initial holder 
since lastforward may be set to any of its adjacent processes, but that the initial state 
of the remaining processes is unique. 
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As indicated above, the state of M is determined by a set messages of messages 
to deliver (either request or grant messages) together with the identity of the sender 
and receiver of the message. More formally, messages is a set of triples of the form 
(v, w, request) or (v, w, grant) denoting messages to be delivered from v to w. The initial 
state of M is the state in which messages is empty, the state in which no messages are 
undelivered. 


3.3.2 The Actions of A, and M 


The actions of A, are given in Figure 3.5. The input actions are those actions of the 
form recetverequest(v,a) and receivegrant(v,a), and the output actions are of the form 
sendrequest(a,v) and sendgrant(a,v), where v is a node (process) adjacent to a in the 
graph G. These actions behave just as described above. There are no internal actions 
of Ag. 


The actions of M are given in Figure 3.6. The input actions are those actions of. 
the form sendrequest (a, a’) and sendgrant (a,a'), and the output actions are of the form 
receiverequest(a,a') and recesvegrant (a,a'), where a and a’ are adjacent arbiter nodes 
of G. These actions accept messages to be delivered by placing them in the message 
buffer messages, and deliver them by removing them from the buffer. There are no 
internal actions of M. 


3.3.3 The Automaton A; 


The composition of the automata A, modeling the arbiter processes together with 
the automaton M modeling the message system yields a global model of the arbiter. 
However, we must hide actions that are inherently internal to the arbiter. Therefore, 
we define the automaton As to be the composition of the automata A, together with 
the automaton M, after hiding all output actions of the composition except those of the 
form sendgrant(a,u) (where a and wu are adjacent arbiter and user nodes, respectively). 


3.3.4 The Execution Module £; 


As mentioned in the introduction to this model, an arbiter process a is required to 
forward all requests, and to grant the resource to a requesting process if the arbiter 
process holds the resource. Let v and w be two nodes adjacent to the arbiter node a, 
and let us define the following sets of states and actions. 


Input Actions: 
receiverequest{v, a) 
effects: 
requesting + requesting U {v} 
recetvegrant(v, a) 
effects: 
if holding = false and lastforward = v then 
holding — true 
requested «— false 


Output Actions: 
sendrequest(a, v) 
preconditions: 
requesting ~ @ 
requested = false 
holding = false 
lastforward = v 
effects: 
requested «— true 
sendgrant(a, v) 
preconditions: 
v © requesting 
holding = true 
lastforward = w 
y ¢ requesting for all y € (w,v) 
effects: 
requesting — requesting — {v} 
lastforward = v 
holding — false 


Figure 3.5: The Actions of A,. 
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Input Actions: 
sendrequest (a, a’) 
effects: 
messages «— messages U {(a, a’, request)} 
sendgrant (a, a’) 
effects: 
messages — messages U {(a, a’, grant)} 


Output Actions: 
receiverequest(a, a’) 
preconditions: 
(a, a’, request) € messages 
effects: 
messages <— messages — {(a, a’, request )} 
recetvegrant (a, a’) 
preconditions: 
(a, a’, grant) € messages 
effects: 
messages + messages — {(a, a’, grant)} 


Figure 3.6: The actions of M. 


FwdReqi(v) {s € states(A,) : requesting # 9, 
requested = false, 
holding = false, and 


lastforward = v in s} 


FwdReqg3(v) = {receivegrant (v, a), sendrequest (a, v)} 
FwdGri(v,w) = {8 € states(A,) : v € requesting 
holding = true, and 
lastforward = w in s} 
FuwdGri(v,w) = {sendgrant(a,y) : y € (w,v]} 


The condition 
FwdReq, = (\\ FwdReq:(v) — FwdReq?(v) 
v 


says that the arbiter process a having received a request and not holding the resource 
will either forward a request for the resource or receive the resource (without having 
requested it, perhaps from a user). The condition 


FwdGr, = (\\ FwdGri(v) 4 FwdGr3(v) 


says that the arbiter process a holding the resource and having received a request will 
eventually forward the resource to a requesting process. The condition 


C, = FwdReq, \ FwdGr, 


is the desired correctness condition for the arbiter process a. We note the following. 
Lemma 42: Every fair execution of A, satisfies C,. 


Proof: Let s be a state of FwdReq’(v) and let z be an execution fragment of A, from s. 
If neither receivegrant (v,a) nor sendrequest (a,v) appear in x, then sendrequest (a,v) is 
enabled from every state appearing in x. Therefore, every fair execution of A, satisfies 
FwdReq,. Similarly, let s be a state of FwdGri(v,w) and let z be an execution fragment 
of A, from s. If no action of FwdGr?(v,w) appears in z, then again an action from this 
set is enabled from every state appearing in z. Therefore, every fair execution of A, 
satisfies FwdGr,. It follows that every fair execution of A, satisfies C,. 


We let the execution module E, = Fair(A,). Recall that an object O solves (the 
problem specified by) an object O’ only if it is implementable. Since FE, is part of our 
solution to the arbiter’s problem specification, it is necessary to show that FE, (as well as 
every other execution module defined at this low level of abstraction) is implementable. 


Lemma 43: E, is implementable. 
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We must also require that the message system deliver all messages sent. Let a 
and a’ be two adjacent arbiter processes, and let us define the following sets of states 
and actions. 


DelReg,, (a, a’) 
DelRegi, (a, a’) 


DelGri,(a, a’) 
DelGr, (a, a’) 


{8 € states(M) : (a,a', request) € messages in s} 
{recetverequest(a, a’)} 


{s € states(M) : (a,a’, grant) € messages in s} 
{recesvegrant (a, a')} 


If we let 
DelRequ, = {\ DelRegy(a, a’) + DelRegh,(a, a’) 
and 
DelGruy = f\ DelGri,(a, a’)  DelGri,(a,a’), 
then the condition 
Cu = DelReqy, A DelGru 


says that messages sent are always delivered. We denote by Ex the execution module 
of M with the executions satisfying Cag. 


Lemma 44: Ex is implementable. 


Proof: It is easy to construct an automaton M' with the action signature of Ex, whose 
fair executions are executions of Exyz: The automaton M' keeps messages to be delivered 
in a FIFO buffer, and delivers them in the order in which they are received for delivery. 


O 


Finally, we define Es to be the composition of the execution modules E, and En 
after hiding the internal actions of As. As a result of Lemma 26, we have the following. 


Lemma 45: Es is implementable. 


3.3.56 The Execution Module E; 


As with the execution module £3, it is necessary to rename the actions of Hs to be 
consistent with the names of E;. As mentioned when we defined the buffer nodes 6,4), 
the arbiter node a sends a message to the arbiter node a’ by placing an arrow on the 
edge (a,5..4') between a and the buffer node 6, .,, and the message system delivers the 
message by placing an arrow on the edge (b,,4',a’) between the buffer node and a’. An 
arbiter node and user node communicate by placing an arrow on the edge between 
them. Therefore, if a is an arbiter node and a’ and wu are arbiter and user nodes, 
respectively, adjacent to a in G, we define the action mapping f2 to map 
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receiverequest(u,a) to request(u,a) 
receivegrant(u,a) to grant(u,a) 

sendrequest(a,u) to request(a,u) 
sendgrant(a,u) to grant(a,u) 


receiverequest(a',a) to request (baa, @) 
recetvegrant(a',a) to grant(bga,a) 

sendrequest(a,a') to request(a, baa’) 
sendgrant(a,a’) to grant(a,b,.’) 


We will denote by A, the automaton f,(As), and in general we will denote by affixing 
a prime to its name the entity obtained by renaming its actions according to f2. 


3.3.6 The Solution of E, by E; 


We begin the proof that Ej satisfies E, by exhibiting a possibilities mapping from Aj 
to A;. In order to define this mapping, it will be necessary to refer to state variables 
from each of the components of Aj. While the name of the state variable messages 
of M' is unique to M', the remaining components share variable names. In order to 
avoid ambiguity, we will indicate the component to which a state variable belongs by 
subscripting the variable with an appropriate identifier. For example, the set requesting 
of requesting processes in A’ will be denoted by requesting,. The mapping hz maps 
the state s of A§ to the set of states t of A; satisfying the following conditions: 


U1 request € arrows(u,a) iff u € requesting, 

U2 grant € arrows(u,a) iff holding, = true and lastforward, = u 
U3 request € arrows(a,u) iff requested, = true and lastforward, = u 
U4 grant € arrows({a,u) iff holding, = false and lastforward, = u 
Al request € arrows (bya,a) iff a’ € requesting, 

A2 grant € arrows(ba4,a) iff holding, = true and lastforward, = a’ 
A3 request € arrows(a,b,') iff requested, = true and lastforward, = a’ 
A4 grant € arrows(a,bga') iff (a,a', grant) € messages 

yal request € arrows (a, baa’), 


request ¢ arrows(b,q',a'), 
and grant ¢ arrows(a',baa') iff (a,a’, request) € messages 
I2 (a, baa") points toward the root iff holding, = false and lastforward, = a’ 


The conditions U1 — U2 and Al — A4 are straightforward. They say that the arbiter 


process a has received a request from a process v in ¢ iff v is in a’s set requesting of 
requesting processes in s, and that a has received the resource from v in ¢ iff a holds the 
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resource in s and last sent (and hence received) the resource from v. Similarly, a has 
forwarded a request for the resource in ¢ iff a has sent a request in the direction it last 
forwarded the resource in s. A4 says that the resource is in transit between a and a’ 
in t iff there is a grant message from a to a’ in the message buffer messages in s. U4 
says that the user u has the resource in t if in s the node a last forwarded the resource 
to u and has not received the resource since. Conditions J1 and /2 are invariants that 
must be preserved by the mapping. /1 says that a state with a request in transit must 
map only to states satisfying Lemma 41. /2 says that the value of lastforward correctly 
records the direction of the resource in the network. We now have the following. 


Lemma 46: The mapping h, is a possibilities mapping from A§ to Ag. 


Proof: The action mapping f, has renamed the actions of As so that A, and A; have 
the same external action signature. Let s be a start state of Aj. For every arbiter 
process a in s, the set requesting, of requesting processes is empty, and requested, is 
set to false. It follows by U1, U3, Al, and A3 that no arrow set of any state in h2(s) 
contains a request arrow. Furthermore, the initial holder a in s has set its flag holding, 
to true; all other processes a’ have set holding,, to false, and lastforward ,, to the node 
in the direction of the resource; and no grant message is pending in the message buffer 
messages. It follows by U2, U4, A2, and A4 that there is precisely one root in every 
state of h(s). Therefore, h2(s) contains a start state of A; as desired. 


Consider the action 7 = request (u, a) of A§, originally the action receiverequest(u, a) 
of As. Suppose s and ¢ are reachable states of A, and A:, respectively, such that 
t € h2(s). The action 7 is an input action of both automata, and hence is enabled from 
both s and t. Suppose s + s' and t — t'. To show that t’ € ha(s'), we must show 
that U1 holds. However, x adds u to the set requesting, of requesting processes is 3’, 
and adds a request arrow to the set arrows(u,a) in t', and hence U1 holds. Therefore, 
t' € ho(s'). 

Consider the action * = grant(u,a) of Aj, originally the action recetvegrant (u, a) 
of As. Suppose s and ¢ are reachable states of A, and A3, respectively, such that 
t € he(s). Since x is an input action in both automata, 7 is enabled from both s 
and t. Suppose s > s' and t > t'. We see by U4 that there is a grant arrow in the set 
arrows (a,u) of t iff holding, = false and lastforward, = u in s. If both conditions are 
false, then 7 has no effect on either state, and hence t € h3(s) implies t’ € h2(s'). On 
the other hand, suppose both conditions are true. To show t' € h2(s'), we must show 
that U2, U3, and U4 hold. Notice that lastforward, = u in s'. First, 7 sets holding, 
to true in s', and adds a grant arrow to arrows (u,a) in t', so U2 holds. Second, x sets 
requested, to false in s', and removes any request arrow from the set arrows(a,u) in t’, 
so U3 holds. Finally, since 7 sets holding, to true in s', the fact that 7 moves the grant 
arrow from arrows (a,u) to arrows(u,a) implies that U4 holds. Therefore, t' € h2(s’). 


Consider the action 7 = request(a,u) of Aj, originally the action sendrequest (a, u) 
of As. Suppose s and ¢ are reachable states of A, and A2, respectively, such that 
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t € h;(s). If m is enabled from s, then the set requesting, of requesting processes is 
nonempty in s, so U1 and Al implies that some set arrows(w,a) contains a request 
arrow in ¢. Furthermore, since holding, = false and lastforward, = u in 8, we have 
by U4 that arrows(a,u) contains a grant arrow in t, and hence that the edge (a, u) 
points toward the root in t. Finally, since requested, = false in 8, by U3 we have that 
arrows (a,u) does not contain a request arrow. Therefore, 7 is enabled from t. Suppose 
ss’ and t + ?'. To see that t' € h,(s'), we must show that U3 holds. Notice that x 
sets requested, to true in s', and that lastforward, = u in s'. Since 7 adds a request 
arrow to arrows(a,u) in t', we see that U3 holds. Therefore, t' € A;(s’). 


Consider the action = grant(a,u) of A§, originally the action sendgrant (a, u) 
of As. Suppose s and ¢ are reachable states of A, and Aj, respectively, such that 
t € h2(s). If x is enabled from s, then wu is contained in the set requesting, of requesting 
processes in s, and U1 implies that arrows(u, a) contains a request arrow. Furthermore, 
holding, = true and lastforward, = w in 8, so U2 and A2 imply that arrows (by4, a) 
(or arrows(w,a) if w is a user node) contains a grant arrow in t. In addition, since 
y & requesting, for all y € (w,u) in s, U1 and Al imply that in ¢ no set arrows (b, 4,4) (or 
arrows (y,a) if y is a user node) contains a request arrow for any y € (w,u). Therefore, x 
is enabled from t. Suppose s ~ s' and t + t'. To show that t’ € h;(s'), we must show 
that U1, U2 and A2, U3 and A3, and U4 hold. First, the action x removes u from 
requesting, in s', and removes a request arrow from arrows(v,a) in t', so U1 holds. 
Second, since holding, is set to false in s', and since a is not a root in t', U2 and A2 
hold. Third, since holding, = true in 8, we see that requested, = false in s and hence 
in s’, so U3 and A3 hold. Finally, since x sets holding, to false and lastforward, to 
u in s’, and since 7 adds a grant arrow to arrows(a,u) in t', we see that U4 holds. 
Therefore, t' € h2(s'). 


Consider the action * = request (ba:a,a) of Ag, originally receiverequest(a',a) of As. 
Suppose s and ¢ are reachable states of A, and A2, respectively, such that ¢ € A;(s). 
If x is enabled from s, the set messages of undelivered messages in s must contain a 
request message from a’ to a. It follows by J1 that in ¢ the set arrows(a’,b.,) contains 
a request arrow, the set arrows(b,,,a) does not contain a request arrow, and the set 
arrows (a, bgq') does not contain a grant arrow. Since arrows (a’, ba.) contains a request 
arrow, Lemma 36 implies that (a’,b,:,) points toward a root. This together with the 
fact that arrows(a, ba.) does not contain a grant arrow implies that (b.:4,a) points 
toward the root as well. Therefore, the action 7 is enabled from t. Suppose s — s' and 
t . t'. In order to see that t’ € A2(s’), we must show that Al and J1 hold. First, x 
adds a’ to the set requesting, of requesting processes in s', and m adds a request arrow 
to arrows (ba a,@) in t', so Al holds. Second, * removes a request message from a’ to a 
from the set messages of undelivered messages in s’, and m adds a request arrow to 
arrows (ba',4,a@), 80 I1 holds. Therefore, t' € h2(s'). 


Consider the action * = grant (bq, a) of A$, originally the action recesvegrant (a', a) 
of As. Suppose s and ¢ are reachable states of A, and A, respectively, such that 
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t € ha(s). If x is enabled from s, the set messages of undelivered messages in s must 
contain a grant message from a’ to a. By A4 we see that the set arrows (a’, ,:,4) contains 
a grant arrow in t. Lemma 41 implies that the set arrows (a, 6,4) must contain a request 
arrow. Since the degree of the buffer node 6,4: is 2, we see that 7 is enabled from t. 
Suppose s — s' and t — t'. Since the set arrows (a, 6.4’) contains a request arrow in t, 
Lemma 36 implies that the edge (a, 6,4) points toward the root. By [2 we see that 
holding, = false and lastforward, = a' in s. Therefore, to see that t’ € h2(s'), we 
must show that A2, A3, A4, and J2 hold. First, sets holding, to true in s'. Notice 
that lastforward, = a’ in s, and therefore in s’ as well. Since * adds a grant arrow to 
arrows (baa, a) in t', we see that A2 holds. Second, x sets requested, to false in s', and + 
removes a request arrow from arrows(a,b,4') in t', so A3 holds. Third, 7 removes a 
grant message from a’ to a from the set messages of undelivered messages in s', and x 
removes a grant arrow from arrows(a', 6,4) in t', so A4 holds. Finally, since holding, 
is set to true in 8’, it is easy to see that [2 holds. Therefore, t' € h2(s'). 


Consider the action = request (a, ba.a') of A, originally the action sendrequest (a, a’) 
of As. Suppose s and ¢ are reachable states of Aj and A, respectively, such that 
t € ha(s). If w is enabled from s, then the set requesting, of requesting processes is 
nonempty in s, and hence by U1 and Al some set arrows(w,a) of t contains a request 
arrow. Furthermore, since holding, = false and lastforward, = a’ in s, by [2 we see 
that the edge (a, 6,41) points toward the root in t. Finally, since requesting, = false 
in s, by A3 we see that there is no request arrow in arrows(a,b,4:) in t. Therefore, x 
is enabled from t. Suppose s — s' and t + t’. To see that ¢t’ € h2(s'), we must show 
that A3 and J1 hold. Notice that sets requested, to true in s', and places a request 
arrow in arrows (a, 6,a') in t'. Since lastforward, = a' in s and hence in s', we see that 
A3 holds. Notice that requested, = false in 8. Since lastforward, = a' in s, A3 implies 
that arrows (a, ba.4:) does not contain a request arrow in t. Lemma 41 implies that there 
is no request arrow in arrows (b,4',@) and no grant arrow in arrows(a',b,4') in t, and 
hence the same is true in t’. Since 7 adds a request arrow to arrows(a,b,4') in t’, and 
adds a request message from a to a’ to the set messages of undelivered messages in s', 
we see that J1 holds. Therefore, t' € h3(s'). 


Finally, consider the action x = grant (a, b,,') of Ag, originally sendgrant (a, a’) of As. 
Suppose s and ¢ are reachable states of A and A;, respectively, such that ¢ € A,(s). 
If x is enabled from s, then since a’ € requesting, in 8, we see by Al that arrows (b,: 4, a) 
contains a request arrow in t. Since holding, = true and lastforward, = w in 8, we see 
by U2 and A2 that a grant arrow must be contained in arrows (b,,.,@) (or arrows (w,a) 
if w is a user node) in t. Furthermore, since y ¢ requesting, for all y € (w,a’) in s, we 
see by U3 and A3 that no request arrow is contained in arrows (b,,a) (or arrows (y, a) 
if y is a user node) in t. Therefore, x is enabled from t. Suppose s > s' and t + ?'. 
To see that t' € h2(s’), we must show that Al, A2 and [2, A4, J1, and J2 hold. All 
except J1 are straightforward, so we show J1. Notice that arrows(ba',,a) contains a 
request arrow in t. By /1, there is no undelivered request message from a’ to a in the 
set messages of s, and hence in s’. However, x puts a grant arrow in arrows (a, ba’), 
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#o I1 holds. Therefore, t' € h2(s'). O 


Having exhibited a possibilities mapping hz from A§ to A:, we now use this map- 
ping together with Lemma 33 to show that Ej satisfies E,. Before using Lemma 33, 
however, we must translate the local correctness conditions C) and Cy for E' and E},, 
respectively, into a global correctness condition for Ey. We use Lemma 34 to recharac- 
terize EZ} in this way. Let a and a’ be adjacent arbiter nodes, and let v be an arbitrary 
(user or arbiter) node adjacent to a in G. Let 


FwdReq’(v)' = {a € states(A,) : al|A, € FwdReg’(v)} 
FwdGri(v)' = {a € states(Ay) : alA, € FwdGri(v)} 
DelReg,(a,a’')' = {a € states(A,) : a|M’ € DelReqi,(a,a’')} 
DelGri,(a, a’)' = {a € states(A,) : a|M' € DelGri,(a,a')}. 
Furthermore, let 
FwdReq), = /|\ FwdReq!(v)' — FwdReq?(v)' 
FwdGr, = \\ FwdGri(v)' > FwdGri(v)'. 


DelReqy, = |\ DelRegy,(a, a’)! + DelReg,,(a, a’)! 


DelGryg = \\ DelGry,(a,a’)' > DelGr,(a,a’)'. 
a,a! 
Finally, let 
C! = FwdReq’, A FudGr, 
Cl, = DelReqy, A DelGryg. 
If 


CL=ACLA Cy 
then the following is an immediate result of Lemma 34. 


Lemma 47: £7} is the execution module of A, with the executions of Ag satisfying C3. 


Having made this transformation from local to global correctness conditions, we 
now use Lemma 33 to show that Ey satisfies Ey. 


Lemma 48: £3 satisfies E32. 
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Proof: Let a and a’ be adjacent arbiter nodes, and let v and w be arbitrary nodes 
adjacent to a. If v is an arbiter node, then let v' be the buffer node 6,, between a 
and v; and let v’ be the node v itself if v is a user node. The node v’ is simply the node 
of G adjacent to a such that the edge (a, v') points toward v. Let w’ be the analogous 
node with respect to w. We will show that 


1. hy}(FwdReg}(a,v')) C FwdReq?(v)' 
2. hz'(FwdReq$(ba,a')) C DelReg,(a,a’)' 
3. hy'(FwdGr}(a,v', w')) C FwdGri(v,w)', and 
4. hy'(FwdGr}(ba4',@,@')) C DelGr,,(a',a)' 
Since it is easy to see from the definition of fz and the following sets that 
1. FwdGr2(v)' C FwdReg3(a, v'), 
. DelRegh,(a'a)' C FwdReq} (bas, 2), 
. FwdGri(v,w)! C FwdGr}(a,v',w’), and 
. DelGry,(a', a)’ C FwdGr} (bac, @), 


mm» CO Ww 


it will follow by Lemma 33 that Ej satisfies E. 


First, suppose t € h;(s) is a state of FwdReq}(a,v'), and let us show that s is a state 
of FwdReqi(v)’. Since some set arrows(w,a) of t contains a request , we see by U1 and 
Al that the set requesting, of requesting processes is nonempty. Since (a,v’) points 
toward the root in ¢, we see by U4 and /2 that holding, = false and lastforward, = v 
in 8. Since the set arrows(a,v') does not contain a request arrow in t, the fact that 
lastforward, = v together with U3 and A3 imply that requested, = false. Therefore, 
8 © FwdReqi(v)!. 


Second, suppose ¢t € h2(s) is a state of FwdReq3(ba4',a'), and let us show that s is a 
state of DelReqg,,(a,a’)’. Since in ¢ there is a request arrow in arrows (w, 6.4’) for some w, 
the edge (w,6,4') must point toward the root . Since (ba,4/,a') also points toward the 
root in ¢, and since this root is unique, this request arrow must be in arrows (a, 6,0"). 
Furthermore, since (5,,4',a') points toward the root, we see that there can be no grant 
arrow in arrows(a’,b,.4') and no request arrow in arrows (b,q,a'). It follows by J1 that 
there is a request message from a to a’ in the set messages of undelivered messages 
in s. Therefore, s € DelRegi,(a,a’)'. 


Third, suppose t € h3(s) is a state of FwdGr}(a,v',w'), and let us show that s is 
a state of FwdGri(v,w)'. Since there is a request arrow in arrows(v',a) in t, U1 and 
Al imply that v is contained in the set requesting, of requesting processes. Since there 
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is a grant arrow in arrows(w',a) in t, U2 and A2 imply that holding, = true and 
lastforward, = w in s. Therefore, s € FwdGri(v,w)'. 


Finally, suppose t € ha(s) is a state of FwdGr}(b,4',a, a’), and let us show that s is 
a state of DelGrj,(a’,a). Since there is a grant arrow in arrows (a',bg,4') int, A4 implies 
that there is a grant message from a’ to a in the set messages of undelivered messages 
in s. Therefore, s € DelGri,(a’,a)'. 0 


Finally, combining the work of the last few section, we have the following result. 
Let Ey be the execution module obtained by renaming the actions of Es according to 
the action mapping f; f2. 


Theorem 49: £9 solves Ej. 


Proof: Since Ej satisfies E, it follows by Lemma 27 that EJ satisfies Ej. Since E} 
satisfies E,, it follows by Lemma 26 that Ef satisfies E,. Since Ey is implementable, 
Lemma 27 implies that Ey is implementable. Therefore, Eg solves FE). O 


With this we have proven the correctness of a fully-detailed protocol for resource 
allocation in an asynchronous network. 


3.4 Time Complexity 


The primary concern motivating Schénhage’s arbiter is its time performance. For 
example, Lynch and Fischer consider two simple resource arbiters in {[LF81], allocating 
a resource among n users. One arbiter is a process that simple polls each user in round- 
robin order, granting the resource to each requesting user in turn. Given that each user 
uses the resource for a bounded amount of time, the response time for this arbiter (the 
maximum time a user must wait for the resource) is O(n) regardless of the number of 
users requesting the resource. A second arbiter is a binary tree (a tournament tree) 
with the users at the leaves of the tree. Each internal node of the tree repeatedly 
polls its children until one of its children requests the resource, at which point it stops 
and passes the name of the child up to the internal node’s parent. The root of the 
tree actually determines which user is granted the resource. When only one user is 
requesting the resource at a time, this arbiter’s response time is only O (logn). In the 
worst case, however, (when every user is requesting the resource) this arbiter’s response 
time is O (nlogn). Schénhage’s algorithm, in contrast, combines favorable aspects of 
both these arbiters. In particular, (in the case that the graph G is a binary tree) the 
arbiter’s response time is O (logn) if only one user requests the resource at a time, and 
O(n) in the worst case. In this section we perform the complexity analysis needed to 
make these claims precise. 
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For convenience, we perform our complexity analysis at the middle level of abstrac- 
tion, with the automaton A,. We have not yet introduced the notion of time into our 
model. While we have not yet decided on how time should be incorporated into our 
model, one alternative is to assign times to states (or equivalently to actions) denoting 
the time at which an automaton transition causes the automaton to enter this state. 
Let us refer to such an execution as a timed execution. In order to perform any time 
analysis, it is necessary to place bounds on the time between automaton transitions. 
Recall that all liveness conditions required of the automaton A, in the construction 
of FE; are of the form S <> T, meaning that if A; enters a state of S, then eventually 


an action of T is performed. Let us denote by S 4 T the condition that if A, enters a 
state s of S, the within time 6 an action x of T will be performed. That is, following 


state s in a timed execution satisfying S “+ T there is a x-step to a state s’ such that 
the difference in times assigned to s and s' is at most b. Let 


BndedFwdReq, = /\ FwdReq;(a,v) —» FwdReq3(a, v) 
av 


BndedFwdGr, = /\ FwdGri(a,v,w) <> FwdGr3(a,v, w) 


BndedRtnRes, = /\ RinRes}(u) * RtnRes*(u) 


Let us say that a timed execution of A; is b-bounded if it satisfies the conditions 
BndedFwdReq,, BndedFwdGr,, and BndedRitnRes,. We define the response time in 
a b-bounded execution z of Az to be a time r such that for all states s with request € 
arrows (u,a) (where u is a user node) appearing in z, the difference in times assigned 
to s and the first state with grant € arrows(a,u) appearing after s in z is less than r. 


Suppose the graph G has diameter d. It is easy to see that the response time for 
b-bounded executions of A; is 2bd when only one user request the resource at a time: 
The request must travel the diameter of the graph to the root, and the root must be 
moved the diameter of the graph to the user. Thus, we have the following. 


Theorem 50: If the diameter of the graph G is d, then the response time in 6-bounded 
executions of A, in which at most one user requests the resource at a time is 2bd. 


Conversely, suppose the graph G has e edges. We now show that the worst-case 
response time (when the arbiter is heavily loaded) is 3be — 6. We begin with the 
following preliminary lemma, the inductive statement in the proof that the arbiter’s 
response time is 3be — 6. Given an edge (v,w), we define e(v,w) to be the number of 
edges in the subtree of v rooted at w. 


Lemma 51: Let s be a state of A; in which request € arrows(v,w) and the edge 
(v,w) points toward the root. In any b-bounded execution fragment of A; from s, 
grant € arrows(w,v) within time 3be(v, w) + 5. 
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Proof: We proceed by induction on e = e(v,w). Suppose e = 0. In this case, w 
must be a leaf, and hence a user node. Since the edge (v,w) points toward the root, 
grant € arrows(v,w). Since w is a user node, condition BndedRtnRes, implies that 
grant € arrows(w,v) within time b = 3be + 0. 


Suppose e > 0 and the inductive hypothesis holds for numbers of edges less that e. 
By assumption, the edge (v,w) points toward the root. If w itself is the root, since 
request € arrows(v,w), condition BndedFwdGr, implies that within time we have 
grant € arrows(w,z) for some node z. Notice that if x = v, then we are done, 
so let us assume that s # v. Then in either case, regardless of whether w itself 
is the root, the edge (w,z) points toward the root within time 6 for some node z 
other than v. Let xz = 2,,...,2,,v be the nodes between z and v in the ordering 
of nodes adjacent to w. Let e; = e(w,z;), and notice that e > D§.,(e; +1). We 
proceed by induction on 1 to show that if request € arrows(v,w) and (w,z,) points 
toward the root, the grant € arrows(w,v) within time D}_, 36(e; + 1). It will fol- 
low that grant € arrows(w,v) within time 6 + D%., 3b(e; + 1) < 3be + 6 of the time 
request € arrows(v,w). The case of 1 = 0 is vacuously true. Suppose s > 0 and the 
inductive hypothesis holds for 1 — 1. Since request € arrows(v,w), the edge (w, z;) 
points toward the root, and request ¢ arrows(w,z,;), condition BndedFwdReq, implies 
that either request € arrows (w,z;,) or grant € arrows(z;,w) within time 6. In the case 
that request € arrows(v,w), since the edge (w,z,;) points toward the root, the induc- 
tive hypothesis for e — 1 implies that grant € arrows(z;,w) within time 3be; + 5. In 
either case, grant € arrows(z;,w) within time 3be; + 2b. Since request € arrows(v, w) 
and grant € arrows (z;,w), condition BndedFwdGr, implies that grant € arrows(w,z;) 
within time 6 for some z; € {2;-1,...,21,v}. The inductive hypothesis for 1 ~ 1 implies 
that grant € arrows(w,v) within time Di-} 36(e; +1), for a total of time D}_, 36(e; +1) 
as desired. Oo 


Finally, we have the following. 


Theorem 52: If the graph G has e edges, then the response time in any }-bounded 
execution of A; is 3be — 6. 


Proof: Let s be a state of A; in which request € arrows(u,a) for some user node wu. 
Either grant € arrows(a,u) or the edge (u,a) points toward the root. In the case that 
grant € arrows(a,u), the condition BndedRinRes, implies that grant € arrows(u, a) 
within time b. In either case, request € arrows(u,a) and the edge (u,a) points toward 
the root within time 6. Lemma 51 implies that grant € arrows(a,u) within time 
3be(u, a) + 6 = 3be — 26 for a total of time 3be — 6. 


Thus, as claimed, the response time in b-bounded executions is linear in the diameter 
of the network when the load on the arbiter is light, and linear in the size of the network 
when the load is heavy. We note that when an arbiter node grants the resource to an 
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adjacent node, if it has received a request for the resource, it later forwards a request 
in the direction of the resource. As a result, three messages are sent over the edge 
to the adjacent node: the grant and request messages sent by the arbiter node, and a 
grant message sent to the arbiter node when the node receives the resource. Hence, the 
worst case response time of about 3be. If, however, the arbiter node were to combine 
the grant and request messages sent to the adjacent node, then only two messages would 
traverse the edge between them. We note that in this case the worst case response time 
is 2be. We have chosen to separate the messages in order to make the algorithm easier 
to describe. 
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Chapter 4 


Conclusions 


In this thesis we have introduced a new model of distributed computation in asyn- 
chronous systems. We find this model to be quite expressive, and find that the trans- 
parent, automata-theoretic semantics make reasoning about system behavior relatively 
simple. We have shown how the strong distinction between input and output actions 
captures the game-theoretic interplay between a system and its environment. This 
distinction has been found to be useful when describing the interface between system 
components, and when decomposing a system into modular components (see {Blo87]). 
We have found that the clarity of the interface between system components described 
by automata allows us to express the notion of fair computation quite simply and 
naturally. Finally, we have seen that automata may be used to construct hierarchical 
correctness proofs for distributed algorithms, allowing intuitive reasoning about key 
high-level ideas behind an algorithm’s behavior to be incorporated into a formal proof 
of its correctness. While the framework developed in this thesis has proven to be quite 
useful, there are a number of ways in which it could be enhanced. We now consider a 
few of these enhancements. 


First of all, it would be nice to find a more compact notation, a programming 
language, for defining automata than the precondition/effects style of presentation 
used in this thesis. In particular, since our work is in several ways similar to CCS, 
it would be nice to develop a CCS-like calculus having input-output automata as its 
underlying operational semantics. We note that one aspect of CCS that has not been 
developed for input-output automata is a powerful theory of equational reasoning. We 
do not know if such a theory can be associated with our model. Any results in this 
direction will certainly be valuable, for they will allow us to combine the transparent 
operational semantics of input-output automata with powerful semantic techniques for 
reasoning about system behavior. 


As of yet, we have not attempted to characterize the expressive power of input- 
output automata. Our feeling that our model is generally quite powerful is the result 
of experience, and our feeling that certain aspects of the model (such as the require- 
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ment that an automaton be input-enabled) capture important aspects of asynchronous 
distributed computation. Bloom has made some initial attempts at characterizing the 
expressive power of our model in [Blo86]. In particular, he has characterized the lan- 
guages that can be expressed as the set of schedules of an automaton (resulting from 
arbitrary executions). Left uncharacterized are the languages that can be expressed as 
the set of schedules resulting from fair executions. Another possible characterization 
of interest is the relationship between the expressive power of temporal logic and our 
model. Wolper, Vardi, and Sistla show in [WVS83] that given a formula in a particular 
extension of temporal logic, it is possible to construct a Biichi automaton accepting 
precisely those sequences satisfying the given formula. It might be possible that these 
techniques can be adapted to prove a similar result for input-output automata. 


We note that our model includes a single, simple notion of automaton composition. 
In particular, our composition requires that automata sharing an action » perform 7 
simultaneously whenever 7 is performed by their composition. The intention is that if 7 
is an output action of A and an input action of B, then the simultaneous performance 
of x models communication from A to B. We think of the performance of x as a 
computational step of A causing B to be notified of the arrival of input. However, 
since two processes in an asynchronous system cannot be expected to perform an action 
simultaneously, rather than complicating our notion of composition, we have chosen 
to require that the output actions of automata in a composition be disjoint. This 
has a number of effects on how systems are modeled with automata. For instance, to 
use Hoare’s example of a vending machine (see [Hoa85]), suppose that we construct 
automata modeling humans, and an automaton modeling a vending machine. Humans 
can insert coins into the vending machine (output from humans and input to the vending 
machine). Since we require that the output actions of automata in a composition be 
disjoint, if we compose a collection of humans with the vending machine, each human’s 
output action of inserting a coin must be tagged with an identifier. Thus, the vending 
machine is effectively able to determine which human is inserting a coin, which is not 
necessarily a realistic model of this simple interaction. It might be interesting to study 
other notions of composition that would avoid this problem. One such composition 
might require all automata having 7 as an input action to synchronize with precisely 
one automaton (the same for all) having 7 as an output action. While this is a natural 
notion of composition, the semantics of this composition complicate our model quite a 
bit. We feel that one virtue of our composition is that, as a consequence of Corollary 3, 
reasoning about the enabling of an action in a composition can be carried out by 
reasoning about the state of a single component. This has been found to be very 
convenient in [LM86]. 


While fair computation important to us, we have not made an explicit study of the 
nature of fairness in our model. In fact, we have defined only one of several possible 
notions of fairness (see [Fra86|). We feel that it should be possible to express many 
other notions of fairness in our model, and the study of these definitions in our model 
are of interest to us. 


However, since the primary emphasis of this thesis has been the decomposition of 
correctness proofs, both hierarchically and modularly, we are naturally interested in 
continuing the study of how automata can be used in new techniques of decomposition. 
We have already mentioned the work of [LS84a] and [LLW87]. The authors of these 
papers seem to be using a horizontal decomposition different from any considered in 
our work. In our work we have attempted to decompose systems into modular units 
that can be composed to yield the desired system. Once this decomposition has been 
made, each component can be examined in isolation, simplifying the verification pro- 
cess. In some systems, however, the system components are so heavily interdependent 
that no clean decomposition appears possible. [LS84a] and [LLW87] use the technique 
of “projecting” onto one system component (or algorithm component), abstracting the 
remaining system components to a high-level black box, and reasoning about the re- 
maining “images.” Notice that these images cannot be composed to yield a model of 
the system since each ts a model of the complete system. The work of [LLW87| concerns 
how correctness proofs for each image can be combined into a correctness proof for the 
entire system. This work appears to be quite promising. 


Finally, while this thesis has essentially ignored the notion of time, time is a very 
important part of modern distributed systems. Timeouts, for instance, are a crucial 
part of the fault-tolerance of many communication algorithms. Furthermore, complex- 
ity analysis of algorithms requires some notion of bounds on processor step times and 
message delivery times. We have shown, using rather ad hoc techniques, how rigorous 
reasoning about time complexity can be performed n our model. A very important 
problem is that of incorporating time into our model more naturally, and investigating 
useful properties about time that can be used to reason about time complexity of algo- 
rithms in our model. For instance, what does it mean to compose the timed equivalent 
of execution modules? Another important problem is that of relating complexity results 
obtained at different levels of abstraction. In our example, we analyzed the complexity 
of Schénhage’s arbiter at a level of abstraction higher than the fully-detailed protocol, 
but it is not hard to see how this complexity result translates down to the lower level 
of abstraction. In general, however, relating time complexities at different levels of 
abstraction is a difficult problem. Such problems certainly deserve further study. 
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